From internet-drafts@ietf.org Wed Sep 7 13:21:54 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1795721F8C0A; Wed, 7 Sep 2011 13:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMAvpYkQEUyn; Wed, 7 Sep 2011 13:21:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F10C21F8BFE; Wed, 7 Sep 2011 13:21:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110907202153.16771.81069.idtracker@ietfa.amsl.com> Date: Wed, 07 Sep 2011 13:21:53 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 20:21:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : IANA Interface Type YANG Module Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-iana-if-type-01.txt Pages : 38 Date : 2011-09-07 This document defines the initial version of the iana-if-type YANG module. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-type-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-type-01.txt From internet-drafts@ietf.org Wed Sep 7 13:23:30 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B5F21F8D62; Wed, 7 Sep 2011 13:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArcCAt6DlqWa; Wed, 7 Sep 2011 13:23:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F0B21F8C04; Wed, 7 Sep 2011 13:23:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110907202328.16555.25787.idtracker@ietfa.amsl.com> Date: Wed, 07 Sep 2011 13:23:28 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 20:23:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : A YANG Data Model for Interface Configuration Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-interfaces-cfg-02.txt Pages : 22 Date : 2011-09-07 This document defines a YANG data model for the configuration of network interfaces. It is expected that interface type specific configuration data models augment the generic interfaces data model defined in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-interfaces-cfg-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-interfaces-cfg-02.txt From mbj@tail-f.com Wed Sep 7 13:40:28 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DCF21F8C35 for ; Wed, 7 Sep 2011 13:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huL-CXGrbmos for ; Wed, 7 Sep 2011 13:40:28 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1862721F8C34 for ; Wed, 7 Sep 2011 13:40:28 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 22EF81200039; Wed, 7 Sep 2011 22:37:19 +0200 (CEST) Date: Wed, 07 Sep 2011 22:42:15 +0200 (CEST) Message-Id: <20110907.224215.453866698.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <008d01cc5187$335efe00$6801a8c0@oemcomputer> References: <002201cc4d99$c2cc3680$6801a8c0@oemcomputer> <20110729.083334.304026312.mbj@tail-f.com> <008d01cc5187$335efe00$6801a8c0@oemcomputer> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 20:40:28 -0000 Hi, [found an old unfinished thread...] "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Friday, July 29, 2011 5:33 AM > > Subject: Re: [netmod] snmp configuration data model charter addition > > > > "Randy Presuhn" wrote: > > > Perhaps this is what is meant? > > > 5. Data model for configuring SNMP engines. The model must be > > > capable of representing all SNMP engine configurations possible > > > with the standard SNMPv3 MIB modules. > > > > This is not exactly what the current document tries to do. It is > > capabale of representing all "usable" configurations, but for example, > > the MIBs allow an snmpTargetParamsEntry with: > > > > snmpTargetParamsMPModel = 0 > > snmpTargetParamsSecurityModel = 3 > > > > but this is not possible in the YANG model. > > > > Here's another example: (copy&pasting from a comment...) > > > > # In some cases, the YANG model imposes stricter constraints on valid > > # configurations than the corresponding MIB model. For example, the > > # leaf "/snmp/community/tag" is a leafref, which means that in a valid > > # configuration, it MUST refer to an existing target tag, as defined in > > # ^RFC6020^. There is no such constraint the MIBs. > > Consider this case: > Such a configuration has been put in place using SNMP or other means. > (a) What happens when a NETCONF client attempts to > retrieve that configuration? It would not get these "orphan" parts of the config. > (b) What happens in a configuration backup / restore scenario when > NETCONF is the protocol used to shovel the information around > using this model? You will (probably) loose the "orphan" parts. This only happens if NETCONF and SNMP are used at the same time, on the same device to configure the engine. > It seems to me that this fails to meet one of the most basic configuration > management use cases. I see your point, but I think the pros outweighs the cons. In my experience, such orphan rows have been a source of confusion. In some sense the basic configuration use case still applies; when you take a backup and later restore it, you get the exact same functionality configured as before. /martin From randy_presuhn@mindspring.com Wed Sep 7 17:55:30 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0345D21F8CE5 for ; Wed, 7 Sep 2011 17:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.085 X-Spam-Level: X-Spam-Status: No, score=-101.085 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFmaqKiCrA1x for ; Wed, 7 Sep 2011 17:55:29 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 11ECC21F8CE0 for ; Wed, 7 Sep 2011 17:55:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HCJ4UUDk6dZAcGd0ZXENFQiIsJyfLXFQXfNTy0Wqkf1w57rannWbU3JExbOzhR2w; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.174.150] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R1SvY-0004Dl-31 for netmod@ietf.org; Wed, 07 Sep 2011 20:57:12 -0400 Message-ID: <003501cc6dc2$4b067860$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <002201cc4d99$c2cc3680$6801a8c0@oemcomputer><20110729.083334.304026312.mbj@tail-f.com><008d01cc5187$335efe00$6801a8c0@oemcomputer> <20110907.224215.453866698.mbj@tail-f.com> Date: Wed, 7 Sep 2011 17:57:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee2880c7177b1b6f2637c1c1556cb02956bba350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.174.150 Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 00:55:30 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Wednesday, September 07, 2011 1:42 PM > Subject: Re: [netmod] snmp configuration data model charter addition ... > > > # In some cases, the YANG model imposes stricter constraints on valid > > > # configurations than the corresponding MIB model. For example, the > > > # leaf "/snmp/community/tag" is a leafref, which means that in a valid > > > # configuration, it MUST refer to an existing target tag, as defined in > > > # ^RFC6020^. There is no such constraint the MIBs. > > > > Consider this case: > > Such a configuration has been put in place using SNMP or other means. ... > > It seems to me that this fails to meet one of the most basic configuration > > management use cases. > > I see your point, but I think the pros outweighs the cons. In my > experience, such orphan rows have been a source of confusion. In > some sense the basic configuration use case still applies; when you > take a backup and later restore it, you get the exact same > functionality configured as before. I don't find this persuasive. I think the difference in our perspectives is that I consider a reference to a tag which has not yet been instantiated to be akin to references to a line card which has not yet been installed, rather than an error, and the losing that information in a backup/restore would be a serious bug, rather than a feature. Randy From mbj@tail-f.com Wed Sep 7 23:38:17 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6E121F8BBE for ; Wed, 7 Sep 2011 23:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO+wPrT-rDUF for ; Wed, 7 Sep 2011 23:38:16 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC2421F8B77 for ; Wed, 7 Sep 2011 23:38:16 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 43C95120005A; Thu, 8 Sep 2011 08:35:06 +0200 (CEST) Date: Thu, 08 Sep 2011 08:40:05 +0200 (CEST) Message-Id: <20110908.084005.653943228155958613.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <003501cc6dc2$4b067860$6801a8c0@oemcomputer> References: <008d01cc5187$335efe00$6801a8c0@oemcomputer> <20110907.224215.453866698.mbj@tail-f.com> <003501cc6dc2$4b067860$6801a8c0@oemcomputer> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 06:38:17 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Wednesday, September 07, 2011 1:42 PM > > Subject: Re: [netmod] snmp configuration data model charter addition > ... > > > > # In some cases, the YANG model imposes stricter constraints on valid > > > > # configurations than the corresponding MIB model. For example, the > > > > # leaf "/snmp/community/tag" is a leafref, which means that in a valid > > > > # configuration, it MUST refer to an existing target tag, as defined in > > > > # ^RFC6020^. There is no such constraint the MIBs. > > > > > > Consider this case: > > > Such a configuration has been put in place using SNMP or other means. > ... > > > It seems to me that this fails to meet one of the most basic configuration > > > management use cases. > > > > I see your point, but I think the pros outweighs the cons. In my > > experience, such orphan rows have been a source of confusion. In > > some sense the basic configuration use case still applies; when you > > take a backup and later restore it, you get the exact same > > functionality configured as before. > > I don't find this persuasive. I think the difference in our perspectives > is that I consider a reference to a tag which has not yet been instantiated > to be akin to references to a line card which has not yet been > installed, rather > than an error, and the losing that information in a backup/restore would be > a serious bug, rather than a feature. I agree that pre-provisioning of e.g. line cards is important, and that info must not be lost in a backup / restore scenario. But I think this use case is a bit different than the SNMP config issue. The difference is that the line card reference points outside of the configuration (in this case to a physical resource). The tag-reference is internal to the configuration. If we said that a line card MUST be present in order to be configured, we have a problem if the card is temporarily removed, since during that time the config is invalid. This is why config references in YANG cannot point to non-config nodes. /martin From reid@snmp.com Thu Sep 8 07:04:18 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B952321F8B9A for ; Thu, 8 Sep 2011 07:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt8YuDlfIlyf for ; Thu, 8 Sep 2011 07:04:18 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0729121F8B74 for ; Thu, 8 Sep 2011 07:04:17 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA15012 for ; Thu, 8 Sep 2011 10:06:07 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA14860 for ; Thu, 8 Sep 2011 10:06:06 -0400 (EDT) Message-Id: <201109081406.KAA14860@adminfs.snmp.com> To: netmod@ietf.org From: David Reid In-reply-to: Your message of Wed, 07 Sep 2011 17:57:32 -0700. <003501cc6dc2$4b067860$6801a8c0@oemcomputer> Date: Thu, 08 Sep 2011 10:06:06 -0400 Sender: reid@snmp.com Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 14:04:18 -0000 > > > > # In some cases, the YANG model imposes stricter constraints on valid > > > > # configurations than the corresponding MIB model. For example, the > > > > # leaf "/snmp/community/tag" is a leafref, which means that in a valid > > > > # configuration, it MUST refer to an existing target tag, as defined in > > > > # ^RFC6020^. There is no such constraint the MIBs. > > > > > > Consider this case: > > > Such a configuration has been put in place using SNMP or other means. > ... > > > It seems to me that this fails to meet one of the most basic configuration > > > management use cases. > > > > I see your point, but I think the pros outweighs the cons. In my > > experience, such orphan rows have been a source of confusion. In > > some sense the basic configuration use case still applies; when you > > take a backup and later restore it, you get the exact same > > functionality configured as before. > > I don't find this persuasive. I think the difference in our perspectives > is that I consider a reference to a tag which has not yet been instantiated > to be akin to references to a line card which has not yet been installed, rather > than an error, and the losing that information in a backup/restore would be > a serious bug, rather than a feature. > > Randy > I agree with Randy. I think the yang module should allow the representation of all possible SNMPv3 engine configurations. -David Reid From j.schoenwaelder@jacobs-university.de Thu Sep 8 07:47:10 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E491221F8AED for ; Thu, 8 Sep 2011 07:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.101 X-Spam-Level: X-Spam-Status: No, score=-103.101 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmGyq4dlx8yc for ; Thu, 8 Sep 2011 07:47:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 21C0821F8A70 for ; Thu, 8 Sep 2011 07:47:10 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB58620C02; Thu, 8 Sep 2011 16:49:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id po+yl+aF2jCT; Thu, 8 Sep 2011 16:48:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 982BE20C01; Thu, 8 Sep 2011 16:48:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 192B41A5759B; Thu, 8 Sep 2011 16:48:46 +0200 (CEST) Date: Thu, 8 Sep 2011 16:48:46 +0200 From: Juergen Schoenwaelder To: David Reid Message-ID: <20110908144844.GA30380@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <003501cc6dc2$4b067860$6801a8c0@oemcomputer> <201109081406.KAA14860@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109081406.KAA14860@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 14:47:11 -0000 On Thu, Sep 08, 2011 at 10:06:06AM -0400, David Reid wrote: > > I agree with Randy. I think the yang module should allow the representation > of all possible SNMPv3 engine configurations. > I am not sure I heard Randy asking for all possible configurations. I heard him talking specifically about tag references. Randy, please clarify. The latest proposal for charter text (July 29th) was: 5. Data model for configuring SNMP engines. The model must be capable of representing all meaningful SNMP engine configurations possible with the standard SNMPv3 MIB modules. What this means to me is that for each case where there is not a 1:1 mapping, we need to evaluate whether this causes a restriction on _meaningful_ SNMP engine configurations. So we would have to take decisions case-by-case (painful as it might be - but there have been off-list discussions on some of them). Are you saying you want that anything I can ever express in the many SNMP tables must be representable in the YANG interface and you want to have that stated in the charter update? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Thu Sep 8 09:41:06 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7667F21F8532 for ; Thu, 8 Sep 2011 09:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js8zXkmBK3La for ; Thu, 8 Sep 2011 09:41:06 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id DC34E21F8B5B for ; Thu, 8 Sep 2011 09:41:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ml0N8Fl2y20uFATLXIXs9WeoF9k7o8S/FiNhs1JNgFFHd1q/TeGE4TNzaxvUb0cf; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.50.55] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R1hgn-0004y1-Vh for netmod@ietf.org; Thu, 08 Sep 2011 12:42:58 -0400 Message-ID: <003501cc6e46$6b2a4480$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <003501cc6dc2$4b067860$6801a8c0@oemcomputer><201109081406.KAA14860@adminfs.snmp.com> <20110908144844.GA30380@elstar.local> Date: Thu, 8 Sep 2011 09:43:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee288380a364cc72b4a11f064f6a61f9412fb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.50.55 Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 16:41:06 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "David Reid" > Cc: > Sent: Thursday, September 08, 2011 7:48 AM > Subject: Re: [netmod] snmp configuration data model charter addition > > On Thu, Sep 08, 2011 at 10:06:06AM -0400, David Reid wrote: > > > > I agree with Randy. I think the yang module should allow the representation > > of all possible SNMPv3 engine configurations. > > > > I am not sure I heard Randy asking for all possible configurations. I > heard him talking specifically about tag references. Randy, please > clarify. The specifically disallowed case is in my opinion a clear example of why the netconf infrastructure shouldn't be second-guessing what a "valid" configuration is. From my perspective, if a configuration can be represented in the SNMP engine's (persistent) local configuration datastore, then, for the netconf stuff to be useful for configuration management, it MUST be possible to back up and restore that configuration. > The latest proposal for charter text (July 29th) was: > > 5. Data model for configuring SNMP engines. The model must be > capable of representing all meaningful SNMP engine > configurations possible with the standard SNMPv3 MIB modules. > > What this means to me is that for each case where there is not a 1:1 > mapping, we need to evaluate whether this causes a restriction on > _meaningful_ SNMP engine configurations. So we would have to take > decisions case-by-case (painful as it might be - but there have been > off-list discussions on some of them). > > Are you saying you want that anything I can ever express in the many > SNMP tables must be representable in the YANG interface and you want > to have that stated in the charter update? The problem is the word "meaningful". The SNMPv3 engine MIBs were carefully designed so that things like references to non-existent table rows still have well-defined semantics, and are thus (as far as I'm concerned) quite meaningful. Disallowing such references would be a major change to the semantics. Perhaps someone could give an example of a well-formed (from a MIB perspective) but "meaningless" configuration. Randy From mbj@tail-f.com Thu Sep 8 09:51:31 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4033F21F84BA for ; Thu, 8 Sep 2011 09:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWfGaBvwMFXB for ; Thu, 8 Sep 2011 09:51:30 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A167C21F84B9 for ; Thu, 8 Sep 2011 09:51:30 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 20BBB1200D53; Thu, 8 Sep 2011 18:48:20 +0200 (CEST) Date: Thu, 08 Sep 2011 18:53:20 +0200 (CEST) Message-Id: <20110908.185320.520627241.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <003501cc6e46$6b2a4480$6801a8c0@oemcomputer> References: <201109081406.KAA14860@adminfs.snmp.com> <20110908144844.GA30380@elstar.local> <003501cc6e46$6b2a4480$6801a8c0@oemcomputer> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 16:51:31 -0000 "Randy Presuhn" wrote: > The problem is the word "meaningful". The SNMPv3 engine MIBs were > carefully designed so that things like references to non-existent table > rows still have well-defined semantics, and are thus (as far as I'm > concerned) quite meaningful. Disallowing such references would be > a major change to the semantics. Perhaps someone could give an > example of a well-formed (from a MIB perspective) but "meaningless" > configuration. Previously in this thread I examplified with: The MIBs allow an snmpTargetParamsEntry with: snmpTargetParamsMPModel = 0 snmpTargetParamsSecurityModel = 3 (maybe the DESCRIPTION clause of snmpTargetParamsSecurityModel allows an agent to reject this; it's not entirely clear.) /martin From randy_presuhn@mindspring.com Thu Sep 8 10:26:10 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F5C21F85CE for ; Thu, 8 Sep 2011 10:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIx6gxiwLLmr for ; Thu, 8 Sep 2011 10:26:10 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 376E121F84BD for ; Thu, 8 Sep 2011 10:26:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qh06vfcSfnke2lmJ8KzkwaatGFGlnncPMDAzgDSZIL5+kUog1vhelQKP32tPojFZ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.50.55] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R1iOC-0005xx-Gl for netmod@ietf.org; Thu, 08 Sep 2011 13:27:48 -0400 Message-ID: <000401cc6e4c$ae279020$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <201109081406.KAA14860@adminfs.snmp.com><20110908144844.GA30380@elstar.local><003501cc6e46$6b2a4480$6801a8c0@oemcomputer> <20110908.185320.520627241.mbj@tail-f.com> Date: Thu, 8 Sep 2011 10:28:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee2885dc4eb2046759940ae35e0a67aea9303350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.50.55 Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 17:26:11 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Thursday, September 08, 2011 9:53 AM > Subject: Re: [netmod] snmp configuration data model charter addition > > "Randy Presuhn" wrote: > > The problem is the word "meaningful". The SNMPv3 engine MIBs were > > carefully designed so that things like references to non-existent table > > rows still have well-defined semantics, and are thus (as far as I'm > > concerned) quite meaningful. Disallowing such references would be > > a major change to the semantics. Perhaps someone could give an > > example of a well-formed (from a MIB perspective) but "meaningless" > > configuration. > > Previously in this thread I examplified with: > > The MIBs allow an snmpTargetParamsEntry with: > > snmpTargetParamsMPModel = 0 > snmpTargetParamsSecurityModel = 3 > > (maybe the DESCRIPTION clause of snmpTargetParamsSecurityModel allows > an agent to reject this; it's not entirely clear.) If an implementation does not support a particular combination of values, then the attempt to set snmpTargetParamsRowStatus to active MUST fail. While I would be surprised if any implementation permitted the combination you describe, if some implementation *did* permit that combination, I would expect backup/restore to preserve it, rather than silently deleting it. Randy From mbj@tail-f.com Thu Sep 8 13:12:18 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4596721F8B19 for ; Thu, 8 Sep 2011 13:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hnb5LTSMSfIC for ; Thu, 8 Sep 2011 13:12:16 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B62A521F8B18 for ; Thu, 8 Sep 2011 13:12:16 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 5FD6E1200D5F; Thu, 8 Sep 2011 22:09:05 +0200 (CEST) Date: Thu, 08 Sep 2011 22:14:07 +0200 (CEST) Message-Id: <20110908.221407.473194402.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <000401cc6e4c$ae279020$6801a8c0@oemcomputer> References: <003501cc6e46$6b2a4480$6801a8c0@oemcomputer> <20110908.185320.520627241.mbj@tail-f.com> <000401cc6e4c$ae279020$6801a8c0@oemcomputer> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 20:12:18 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Thursday, September 08, 2011 9:53 AM > > Subject: Re: [netmod] snmp configuration data model charter addition > > > > "Randy Presuhn" wrote: > > > The problem is the word "meaningful". The SNMPv3 engine MIBs were > > > carefully designed so that things like references to non-existent table > > > rows still have well-defined semantics, and are thus (as far as I'm > > > concerned) quite meaningful. Disallowing such references would be > > > a major change to the semantics. Perhaps someone could give an > > > example of a well-formed (from a MIB perspective) but "meaningless" > > > configuration. > > > > Previously in this thread I examplified with: > > > > The MIBs allow an snmpTargetParamsEntry with: > > > > snmpTargetParamsMPModel = 0 > > snmpTargetParamsSecurityModel = 3 > > > > (maybe the DESCRIPTION clause of snmpTargetParamsSecurityModel allows > > an agent to reject this; it's not entirely clear.) > > If an implementation does not support a particular combination of values, > then the attempt to set snmpTargetParamsRowStatus to active MUST fail. > While I would be surprised if any implementation permitted the combination > you describe, if some implementation *did* permit that combination, I > would expect backup/restore to preserve it, rather than silently deleting it. So do you think the requirement is that these combinations must be possible to do in the YANG data model as well, or is the requirement that an explicit backup / restore must preserve them? I also do not think it is obvious that everything you set via SNMP must be part of a proper configuration backup. Do you expect volatile rows be part of the backup (get-config)? nonVolatile rows that are notInService? /martin From randy_presuhn@mindspring.com Thu Sep 8 19:48:13 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FDE21F8B3F for ; Thu, 8 Sep 2011 19:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqnZPSZhZgGX for ; Thu, 8 Sep 2011 19:48:12 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 23C7621F8B3A for ; Thu, 8 Sep 2011 19:48:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Auos7qB3Yqhv+xxa24H6bdGI4s1P9UCHIy5JbfG28gy95Si0cIqXYP3ZTdZFcB7G; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.53.19] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R1rAL-0005o5-8H for netmod@ietf.org; Thu, 08 Sep 2011 22:50:05 -0400 Message-ID: <001201cc6e9b$3b2a0ea0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <003501cc6e46$6b2a4480$6801a8c0@oemcomputer><20110908.185320.520627241.mbj@tail-f.com><000401cc6e4c$ae279020$6801a8c0@oemcomputer> <20110908.221407.473194402.mbj@tail-f.com> Date: Thu, 8 Sep 2011 19:50:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee2886afef12b239a0fe0ee894f0359a0dd02350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.53.19 Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 02:48:13 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Thursday, September 08, 2011 1:14 PM > Subject: Re: [netmod] snmp configuration data model charter addition ... > So do you think the requirement is that these combinations must be > possible to do in the YANG data model as well, or is the requirement > that an explicit backup / restore must preserve them? I'd like to understand how backup/restore built on Netconf can violate the corresponding YANG data model. I'm assuming I'm missing something improtant here. > I also do not think it is obvious that everything you set via SNMP must > be part of a proper configuration backup. Do you expect volatile rows > be part of the backup (get-config)? nonVolatile rows that are > notInService? Whether nonvolatile rows are included should be a user option; if such an option isn't possible, I would not include them in backup/restore. If a row's RowStatus is notInService, the NOTE WELL on page 16 of RFC 2579 applies, and it would not be reasonable to assume that a row in such a state would persist for more 5 minutes if there's not text to the contrary somewhere in that table's DESCRIPTION clauses. consequently, I would exclude such rows from backup/restore. Randy From internet-drafts@ietf.org Thu Sep 8 20:53:50 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269EC21F8AFD; Thu, 8 Sep 2011 20:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QbJsbTVEnGZ; Thu, 8 Sep 2011 20:53:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F7921F85BB; Thu, 8 Sep 2011 20:53:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110909035349.21762.23933.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2011 20:53:49 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 03:53:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : A YANG Data Model for IP Configuration Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-00.txt Pages : 12 Date : 2011-09-07 This document defines a YANG data model for configuration of IP addresses on network interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-ip-cfg-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-ip-cfg-00.txt From mbj@tail-f.com Fri Sep 9 00:31:43 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE51921F8B25 for ; Fri, 9 Sep 2011 00:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISk2LArxymro for ; Fri, 9 Sep 2011 00:31:43 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7EC21F8B1E for ; Fri, 9 Sep 2011 00:31:42 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 630681200D5D; Fri, 9 Sep 2011 09:28:29 +0200 (CEST) Date: Fri, 09 Sep 2011 09:33:33 +0200 (CEST) Message-Id: <20110909.093333.329504282.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <001201cc6e9b$3b2a0ea0$6801a8c0@oemcomputer> References: <000401cc6e4c$ae279020$6801a8c0@oemcomputer> <20110908.221407.473194402.mbj@tail-f.com> <001201cc6e9b$3b2a0ea0$6801a8c0@oemcomputer> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 07:31:43 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Thursday, September 08, 2011 1:14 PM > > Subject: Re: [netmod] snmp configuration data model charter addition > ... > > So do you think the requirement is that these combinations must be > > possible to do in the YANG data model as well, or is the requirement > > that an explicit backup / restore must preserve them? > > I'd like to understand how backup/restore built on Netconf can > violate the corresponding YANG data model. I'm assuming I'm > missing something improtant here. It can't. I am trying to understand your concern. I wonder if you feel it is important to keep the flexibility in these tables, or if the concern is rather that you expect data set using SNMP be part of a NETCONF operation. > > I also do not think it is obvious that everything you set via SNMP must > > be part of a proper configuration backup. Do you expect volatile rows > > be part of the backup (get-config)? nonVolatile rows that are > > notInService? > > Whether nonvolatile rows are included should be a user option; if such > an option isn't possible, I would not include them in backup/restore. > > If a row's RowStatus is notInService, the NOTE WELL on page 16 of > RFC 2579 applies, and it would not be reasonable to assume that a > row in such a state would persist for more 5 minutes if there's not text > to the contrary somewhere in that table's DESCRIPTION clauses. > consequently, I would exclude such rows from backup/restore. Ok. So we agree that not everything set over SNMP must be kept in a . /martin From mbj@tail-f.com Fri Sep 9 06:28:22 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D424F21F86A5 for ; Fri, 9 Sep 2011 06:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgcr04JK967t for ; Fri, 9 Sep 2011 06:28:21 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 93CE421F8680 for ; Fri, 9 Sep 2011 06:28:21 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F36A1200D5F; Fri, 9 Sep 2011 15:25:08 +0200 (CEST) Date: Fri, 09 Sep 2011 15:30:13 +0200 (CEST) Message-Id: <20110909.153013.381801558.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110726164341.GA7684@elstar.local> References: <20110726164341.GA7684@elstar.local> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] js review of draft-bierman-netmod-system-mgmt-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 13:28:22 -0000 Hi, Juergen Schoenwaelder wrote: > I have reviewed draft-bierman-netmod-system-mgmt-00 (as technical > contributor). I am fine with the scope of document and support its > adoption as WG document. The comments come in document order. > > 1) Is there some authoritative reference for the crypt-hash format, > e.g., a POSIX standard? Is this regulated as part of say POSIX.1 or > is all this a GNU invention? Are we sure we can use $0$ as a > cleartext password format? Do we have to state that lowercase > characters are the canonical representation? The POSIX definition of the crypt() function is pretty generic, see http://pubs.opengroup.org/onlinepubs/9699919799/functions/crypt.html. I don't think a canonical representation is needed for this type. > 2) The platform leafs are very Unix specific - is this OK? Can we have > better references than "uname --kernel"? It looks uname is covered > by POSIX.1-2001 but I am not sure. See http://pubs.opengroup.org/onlinepubs/9699919799/functions/uname.html. We should probably add this as reference. > 3) Rename timezone-info leafs, e.g. > > OLD > > choice timezone-info > leaf tz-database-id > leaf tz-enumeration-is > leaf utc-offset > > NEW > > choice timezone > leaf timezone-location > leaf timezone-name > leaf timezone-utc-offset The reason they have these names is that the db seems to go by the name "tz database". See also http://tools.ietf.org/html/draft-lear-iana-timezone-database-04. But if people prefer 'timezone-database', that's fine as well. > 4) Can we reasonably expect to control timeouts and retries for > different implementations of DNS, NTP, or RADIUS? Or should we > leave this to protocol specific modules? If we can expect to control the timeouts and retries, I think we can define them here. If cannot expect to control them, a protocol specific module won't help. Or did I misunderstand your concern? But it should be noted that we basically just put some objects in there in order to get started. We need to discuss more exactly what is needed. > 5) For RADIUS, you include a port number leaf but not for DNS and > NTP. Should we be consistent about this? Consistency is good... But can you typically configure the port for dns and ntp? > 6) What exactly is stored in the ssh-dsa and ssh-rsa leafs? Just the binary key as is. Since there is no other standard format, this seems simplest. > 7) Should we submodularize this YANG module this so that we can more > easily revise parts of the model as we move along? I don't mind submodules. /martin From reid@snmp.com Fri Sep 9 07:32:54 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C11521F8B4B for ; Fri, 9 Sep 2011 07:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpMbNz+buUlt for ; Fri, 9 Sep 2011 07:32:53 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8803B21F88A0 for ; Fri, 9 Sep 2011 07:32:53 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA04063; Fri, 9 Sep 2011 10:34:47 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA06588; Fri, 9 Sep 2011 10:34:46 -0400 (EDT) Message-Id: <201109091434.KAA06588@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Thu, 08 Sep 2011 16:48:46 +0200. <20110908144844.GA30380@elstar.local> Date: Fri, 09 Sep 2011 10:34:46 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 14:32:54 -0000 > Are you saying you want that anything I can ever express in the many > SNMP tables must be representable in the YANG interface and you want > to have that stated in the charter update? Yes. But the current proposed charter text does not preclude what I want, so I have no objection to the proposed text. I prefer the text Randy suggested, but I'm OK with the current proposed text. -David Reid From randy_presuhn@mindspring.com Fri Sep 9 10:18:29 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15AB21F86A1 for ; Fri, 9 Sep 2011 10:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.067 X-Spam-Level: X-Spam-Status: No, score=-101.067 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJlfKRYV4YEA for ; Fri, 9 Sep 2011 10:18:29 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD5B21F8696 for ; Fri, 9 Sep 2011 10:18:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Wma97MaUlx5hn2GdsX/Xsxc7NyDMWBk9y4uor3ATx08MDgGLWYJgm/DZH+AS+V3q; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.53.19] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R24ka-00040d-2F for netmod@ietf.org; Fri, 09 Sep 2011 13:20:24 -0400 Message-ID: <001301cc6f14$d12fc6a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000401cc6e4c$ae279020$6801a8c0@oemcomputer><20110908.221407.473194402.mbj@tail-f.com><001201cc6e9b$3b2a0ea0$6801a8c0@oemcomputer> <20110909.093333.329504282.mbj@tail-f.com> Date: Fri, 9 Sep 2011 10:20:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee288c7147ed0b65cd589ec048bb3ca140464350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.53.19 Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 17:18:29 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Friday, September 09, 2011 12:33 AM > Subject: Re: [netmod] snmp configuration data model charter addition ... > It can't. I am trying to understand your concern. I wonder if you > feel it is important to keep the flexibility in these tables, or if > the concern is rather that you expect data set using SNMP be part of a > NETCONF operation. Neither. (Though to a very limited degree, both.) Assuming the purpose of Netconf is to aid in configuration management, I would like to avoid having the Yang models over-specified in ways that preclude the backup / restore of perfectly valid configurations. For that purpose it seems quite reasonable to use RowStatus / StorageType or text from DESCRIPTION clauses spelling out volatility constraints to decide how to cull information that might be accessible from the SNMP implementation's management infrastructure. What does not seem reasonable is to add constraints to the models which would cause portions of legitimate configurations to silently disappear. ... > Ok. So we agree that not everything set over SNMP must be kept in a > . It's not a question of whether the information came to be by being set using SNMP. It's a question of avoiding gratuitous incompatibilities between the models that would sabotage the most basic configuration management functions. Randy From j.schoenwaelder@jacobs-university.de Fri Sep 9 14:29:03 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6C21F86A2 for ; Fri, 9 Sep 2011 14:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.104 X-Spam-Level: X-Spam-Status: No, score=-103.104 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb5yFW351l+4 for ; Fri, 9 Sep 2011 14:29:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DAE2821F85A1 for ; Fri, 9 Sep 2011 14:29:02 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52F3B20C9B; Fri, 9 Sep 2011 23:30:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lOehW73d1KTe; Fri, 9 Sep 2011 23:30:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0547620C9A; Fri, 9 Sep 2011 23:30:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 29C8F1A59B1D; Fri, 9 Sep 2011 23:30:46 +0200 (CEST) Date: Fri, 9 Sep 2011 23:30:45 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20110909213045.GA35891@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <000401cc6e4c$ae279020$6801a8c0@oemcomputer> <20110908.221407.473194402.mbj@tail-f.com> <001201cc6e9b$3b2a0ea0$6801a8c0@oemcomputer> <20110909.093333.329504282.mbj@tail-f.com> <001301cc6f14$d12fc6a0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001301cc6f14$d12fc6a0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 21:29:03 -0000 On Fri, Sep 09, 2011 at 10:20:47AM -0700, Randy Presuhn wrote: > Assuming the purpose of Netconf is to aid in configuration management, > I would like to avoid having the Yang models over-specified in ways that > preclude the backup / restore of perfectly valid configurations. This is only an issue if someone / something configures an SNMP agent via SNMP and does backup/restore via NETCONF. One could ask whether this is a common use case. > For that purpose it seems quite reasonable to use RowStatus / > StorageType or text from DESCRIPTION clauses spelling out volatility > constraints to decide how to cull information that might be > accessible from the SNMP implementation's management infrastructure. Out of curiosity, how do you treat a row with StorageType permanent(4), -- e.g., partially in ROM if the goal is complete backup/restore via NETCONF? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Fri Sep 9 15:10:13 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D954E21F891D for ; Fri, 9 Sep 2011 15:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.098 X-Spam-Level: X-Spam-Status: No, score=-102.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxEBvmmCfB1k for ; Fri, 9 Sep 2011 15:10:13 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3E021F872A for ; Fri, 9 Sep 2011 15:10:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=d6LjnmhbKNJU+Fp/W78muWt9UxdSBQDtCQWnTkPyFYY6wX86PpKyxJAo3zrflevh; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.51.46] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R29Is-0007KW-Ni for netmod@ietf.org; Fri, 09 Sep 2011 18:12:07 -0400 Message-ID: <000401cc6f3d$8ef04160$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000401cc6e4c$ae279020$6801a8c0@oemcomputer> <20110908.221407.473194402.mbj@tail-f.com> <001201cc6e9b$3b2a0ea0$6801a8c0@oemcomputer> <20110909.093333.329504282.mbj@tail-f.com> <001301cc6f14$d12fc6a0$6801a8c0@oemcomputer> <20110909213045.GA35891@elstar.local> Date: Fri, 9 Sep 2011 15:12:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee288a0b5212464d2dc54eabad99c9d871581350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.51.46 Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 22:10:14 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Friday, September 09, 2011 2:30 PM > Subject: Re: [netmod] snmp configuration data model charter addition ... > This is only an issue if someone / something configures an SNMP agent > via SNMP and does backup/restore via NETCONF. One could ask whether > this is a common use case. I don't know how frequent it would be. I see it more as an argument from first principles of what configuration management is about. If Netconf can't faithfully do backup/restore of something as straightforward as the SNMPv3 MIBs, I'd be very worried about whether it could be trusted to faithfully handled more complex / subtle data models from other environments. > > For that purpose it seems quite reasonable to use RowStatus / > > StorageType or text from DESCRIPTION clauses spelling out volatility > > constraints to decide how to cull information that might be > > accessible from the SNMP implementation's management infrastructure. > > Out of curiosity, how do you treat a row with StorageType > > permanent(4), -- e.g., partially in ROM > > if the goal is complete backup/restore via NETCONF? I agree some though would need to go into both the permanent and readOnly cases. For purposes of doing diffs, backups, and off-line configuration validation, these values would need to be read and preserved. For purposes of doing a restore, the management application doing the restore would need to assess whether the rows in question had already been instantiated on the target system, and, if so, evaluate whether what was there was compatible with the values to be "restored", and if those rows were absent, instantiate functionally equivalent rows with a nonVolatile StorageType. But this is work that needs to be done with *any* existing model that provides for persistant configuration data, whether using StorageType, DESCRIPTION text, or totally ad hoc means. Randy From mbj@tail-f.com Sun Sep 11 10:30:17 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FF621F869E for ; Sun, 11 Sep 2011 10:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP20JwRxrmyQ for ; Sun, 11 Sep 2011 10:30:16 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 824CD21F863E for ; Sun, 11 Sep 2011 10:30:15 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id D4A5B1200D19; Sun, 11 Sep 2011 19:26:56 +0200 (CEST) Date: Sun, 11 Sep 2011 19:32:11 +0200 (CEST) Message-Id: <20110911.193211.254882919.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <000401cc6f3d$8ef04160$6801a8c0@oemcomputer> References: <001301cc6f14$d12fc6a0$6801a8c0@oemcomputer> <20110909213045.GA35891@elstar.local> <000401cc6f3d$8ef04160$6801a8c0@oemcomputer> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2011 17:30:17 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Randy Presuhn" > > Cc: > > Sent: Friday, September 09, 2011 2:30 PM > > Subject: Re: [netmod] snmp configuration data model charter addition > ... > > This is only an issue if someone / something configures an SNMP agent > > via SNMP and does backup/restore via NETCONF. One could ask whether > > this is a common use case. > > I don't know how frequent it would be. I see it more as an argument from > first principles of what configuration management is about. If Netconf can't > faithfully do backup/restore of something as straightforward as the SNMPv3 > MIBs, I'd be very worried about whether it could be trusted to faithfully > handled more complex / subtle data models from other environments. This is off-topic, but yes, NETCONF can do backup/restore of any config data, as long as it can be expressed in XML. In the case of SMI data, one problem is that SMI does not have a notion of what is configuration, so it is not obvious what to include in the reply. By defining a SNMP engine data model in YANG, we make it clear what is configuration. This is, btw, not unique to NETCONF. You have the same (theoretical) problem in current CLIs. The question is not if NETCONF/YANG _can_ do it; it is trivial to do a 1-1 mapping (e.g.; using Juergen's SMI->YANG algorithm, and tweak teh output model to just do config), but the result is pretty useless. The issue right now if whether we take the opportunity to make a simpler data model for configuration, or if we must preserve old model in all details. As Juergen stated, the "problem" (I am not convinced this is a real problem) only occurs if you do config via SNMP, and backup/restore over NETCONF. If this is not common, should we really solve it? And even for the use case where an operator does use SNMP to configure the SNMP engine, but NETCONF for backup / restore, some rows (depending at least on RowStatus and StorageType values) will not be part of the config backup. So if we clearly document which rows are part of the config and which are not, I think we have solved this problem. /martin From randy_presuhn@mindspring.com Sun Sep 11 19:13:48 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B367321F8AA9 for ; Sun, 11 Sep 2011 19:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.974 X-Spam-Level: X-Spam-Status: No, score=-100.974 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL7Q-Lr9nZcy for ; Sun, 11 Sep 2011 19:13:48 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEFB21F88A0 for ; Sun, 11 Sep 2011 19:13:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=APfvuaUNH+h68Yu5TH3ePKkW/RJapFBrU8FD9BJ56UEsJmRoccBNiCDF3Z0et6xd; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.54.47] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R2w3e-0003Qm-VQ for netmod@ietf.org; Sun, 11 Sep 2011 22:15:39 -0400 Message-ID: <001101cc70f1$ef7a4a20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001301cc6f14$d12fc6a0$6801a8c0@oemcomputer><20110909213045.GA35891@elstar.local><000401cc6f3d$8ef04160$6801a8c0@oemcomputer> <20110911.193211.254882919.mbj@tail-f.com> Date: Sun, 11 Sep 2011 19:16:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee288e2c32cc7211db9db57f55cc17cc1fb5b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.54.47 Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 02:13:48 -0000 Hi - > From: "Martin Bjorklund" ... > As Juergen stated, the "problem" (I am not convinced this is a real > problem) only occurs if you do config via SNMP, and backup/restore > over NETCONF. If this is not common, should we really solve it? The problem could also occur for agent-created rows, and for configurations set by internal APIs, as might be used by the disman MIBs. > And even for the use case where an operator does use SNMP to configure > the SNMP engine, but NETCONF for backup / restore, some rows > (depending at least on RowStatus and StorageType values) will not be > part of the config backup. So if we clearly document which rows are > part of the config and which are not, I think we have solved this > problem. "this problem"? At least three distinct problems have been brought up in this thread. (1) identifing the subset of a data model which constitutes potential configuration data (2) deciding how to use the various possible combinations of rowStatus and storageType to determine whether a given row should be backed up how to handle restore for readOnly / permanent configuration data (3) deciding whether use the YANG model to prohibit configurations which would be perfectly OK created via SNMP My primary objection was to (3). The discussion then meandered into (2), and you now seem concerned about (1). (1) has already been dealt with at some length, and I think it is a red herring. (2) admits solutions that will "do the right thing", though it sounds like expressing them in YANG would be difficult, if it is even possible, and would instead have to rely on management application logic above the netconf protocol. I'm not terribly worried about it, even though the details would be a bit gnarly. I remain convinced that (3) is asking for trouble. If this WG believes that fidelity to the capabilities of the SMI-based models is not a requirement, then the charter should explicitly say so. Randy From mbj@tail-f.com Mon Sep 12 01:00:58 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F279221F8770 for ; Mon, 12 Sep 2011 01:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-udTt+vOS94 for ; Mon, 12 Sep 2011 01:00:57 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6C21F86EE for ; Mon, 12 Sep 2011 01:00:56 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 86B3F1200D16; Mon, 12 Sep 2011 09:57:37 +0200 (CEST) Date: Mon, 12 Sep 2011 10:02:56 +0200 (CEST) Message-Id: <20110912.100256.1917495904241382329.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <001101cc70f1$ef7a4a20$6801a8c0@oemcomputer> References: <000401cc6f3d$8ef04160$6801a8c0@oemcomputer> <20110911.193211.254882919.mbj@tail-f.com> <001101cc70f1$ef7a4a20$6801a8c0@oemcomputer> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 08:00:58 -0000 Hi, "Randy Presuhn" wrote: > > From: "Martin Bjorklund" > ... > > As Juergen stated, the "problem" (I am not convinced this is a real > > problem) only occurs if you do config via SNMP, and backup/restore > > over NETCONF. If this is not common, should we really solve it? > > The problem could also occur for agent-created rows, and for configurations > set by internal APIs, as might be used by the disman MIBs. > > > And even for the use case where an operator does use SNMP to configure > > the SNMP engine, but NETCONF for backup / restore, some rows > > (depending at least on RowStatus and StorageType values) will not be > > part of the config backup. So if we clearly document which rows are > > part of the config and which are not, I think we have solved this > > problem. > > "this problem"? Yes I meant (3) below. I agree that (1) and (2) can be handled. > At least three distinct problems have been brought up in this thread. > > (1) identifing the subset of a data model which > constitutes potential configuration data > > (2) deciding how to use the various possible combinations > of rowStatus and storageType to determine whether a > given row should be backed up how to handle restore > for readOnly / permanent configuration data > > (3) deciding whether use the YANG model to prohibit > configurations which would be perfectly OK created > via SNMP > > My primary objection was to (3). The discussion then meandered > into (2), and you now seem concerned about (1). (1) has already > been dealt with at some length, and I think it is a red herring. > (2) admits solutions that will "do the right thing", though it sounds > like expressing them in YANG would be difficult, if it is even possible, > and would instead have to rely on management application logic above > the netconf protocol. I'm not terribly worried about it, even though the > details would be a bit gnarly. I remain convinced that (3) is asking > for trouble. > > If this WG believes that fidelity to the capabilities of the SMI-based > models is not a requirement, then the charter should explicitly say so. /martin From j.schoenwaelder@jacobs-university.de Mon Sep 12 01:21:24 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A8C21F847B for ; Mon, 12 Sep 2011 01:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.106 X-Spam-Level: X-Spam-Status: No, score=-103.106 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlDs2tR27vqJ for ; Mon, 12 Sep 2011 01:21:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BF2C521F841D for ; Mon, 12 Sep 2011 01:21:16 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7CD0220D31; Mon, 12 Sep 2011 10:23:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FyF8ti+24G5J; Mon, 12 Sep 2011 10:23:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC16E20D0D; Mon, 12 Sep 2011 10:23:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 31AAC1A5B32F; Mon, 12 Sep 2011 10:23:03 +0200 (CEST) Date: Mon, 12 Sep 2011 10:23:03 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20110912082303.GB39270@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <000401cc6e4c$ae279020$6801a8c0@oemcomputer> <20110908.221407.473194402.mbj@tail-f.com> <001201cc6e9b$3b2a0ea0$6801a8c0@oemcomputer> <20110909.093333.329504282.mbj@tail-f.com> <001301cc6f14$d12fc6a0$6801a8c0@oemcomputer> <20110909213045.GA35891@elstar.local> <000401cc6f3d$8ef04160$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401cc6f3d$8ef04160$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 08:21:24 -0000 On Fri, Sep 09, 2011 at 03:12:24PM -0700, Randy Presuhn wrote: > > Out of curiosity, how do you treat a row with StorageType > > > > permanent(4), -- e.g., partially in ROM > > > > if the goal is complete backup/restore via NETCONF? > > I agree some though would need to go into both the permanent > and readOnly cases. For purposes of doing diffs, backups, and > off-line configuration validation, these values would need to be read > and preserved. For purposes of doing a restore, the management > application doing the restore would need to assess whether the > rows in question had already been instantiated on the target > system, and, if so, evaluate whether what was there was compatible > with the values to be "restored", and if those rows were absent, > instantiate functionally equivalent rows with a nonVolatile StorageType. > But this is work that needs to be done with *any* existing model > that provides for persistant configuration data, whether using > StorageType, DESCRIPTION text, or totally ad hoc means. So can we conclude that unless an application configured a box via SNMP in the first place, a proper backup/restore of SNMPv3 configuration is in general not possible even with SNMP? As a matter of fact, there are a number of CLIs for configuration of SNMP and it seems there is a certain number of networks where SNMP configuration via interfaces other than SNMP seems attractive. Perhaps the goal of this work is not backup/restore of a configuration done via SNMP but instead configuration and backup/restore via NETCONF but with proper representation to SNMP managers. Does that make sense? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Mon Sep 12 05:10:06 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E1F21F852E for ; Mon, 12 Sep 2011 05:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3aOGil8eJIo for ; Mon, 12 Sep 2011 05:10:04 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3D23321F8AFE for ; Mon, 12 Sep 2011 05:09:23 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTm325gyR4lVKTYjv9VECExiC6hePXNFH@postini.com; Mon, 12 Sep 2011 05:11:29 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 12 Sep 2011 05:10:59 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p8CCAr306077; Mon, 12 Sep 2011 05:10:54 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p8CBhOxN039389; Mon, 12 Sep 2011 11:43:24 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201109121143.p8CBhOxN039389@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20110911.193211.254882919.mbj@tail-f.com> Date: Mon, 12 Sep 2011 07:43:24 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 12:10:06 -0000 Martin Bjorklund writes: >As Juergen stated, the "problem" (I am not convinced this is a real >problem) only occurs if you do config via SNMP, and backup/restore >over NETCONF. If this is not common, should we really solve it? So we define rows where RowStatus isn't active as non-configuration data, just a "work space" for SNMP. In the same way one can't backup/restore invalid configs built inside the candidate database (that would fail any commit operations), one can't backup/restore the snmp work space. This means that activating the row makes it become configuration data, and deactivating the row makes it become non-config data again. Hmmm.... perhaps this resembles the "inactive" configuration we support in JUNOS, where a hierarchy of configuration data can be deactivated, essentially commenting it out of the data we expose to JUNOS subcomponents, while keeping the data in the configuration database. See CLI session transcript below (where deactivating netconf removes it from inetd.conf and activating it restores it). Inactive config is marked with "inactive:" in the CLI and with the "inactive" attribute in XML. Thanks, Phil ------------ [edit] user@cli# edit system services [edit system services] user@cli# show ssh; netconf { ssh; } [edit system services] user@cli# run file show /var/etc/inetd.conf | match netconf netconf stream tcp nowait/75/150 root /usr/sbin/sshd sshd -i -f /etc/sshd_netconf -o SubsystemOnly=netconf netconf stream tcp6 nowait/75/150 root /usr/sbin/sshd sshd -i -f /etc/sshd_netconf -o SubsystemOnly=netconf [edit system services] user@cli# show ssh; netconf { ssh; } [edit system services] user@cli# deactivate netconf [edit system services] user@cli# commit commit complete [edit system services] user@cli# run file show /var/etc/inetd.conf | match netconf [edit system services] user@cli# activate netconf [edit system services] user@cli# commit commit complete [edit system services] user@cli# run file show /var/etc/inetd.conf | match netconf netconf stream tcp nowait/75/150 root /usr/sbin/sshd sshd -i -f /etc/sshd_netconf -o SubsystemOnly=netconf netconf stream tcp6 nowait/75/150 root /usr/sbin/sshd sshd -i -f /etc/sshd_netconf -o SubsystemOnly=netconf [edit system services] user@cli# [edit system services] user@cli# deactivate netconf [edit system services] user@cli# show ssh; inactive: netconf { ssh; } [edit system services] user@cli# show | display xml [edit system services] user@cli# From j.schoenwaelder@jacobs-university.de Mon Sep 12 05:30:52 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6076521F8AFA for ; Mon, 12 Sep 2011 05:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.11 X-Spam-Level: X-Spam-Status: No, score=-103.11 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfKUDvqHe9q1 for ; Mon, 12 Sep 2011 05:30:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEA521F85C7 for ; Mon, 12 Sep 2011 05:30:51 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A06820D0D; Mon, 12 Sep 2011 14:32:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xW6HWGifDx-V; Mon, 12 Sep 2011 14:32:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADD3320D0C; Mon, 12 Sep 2011 14:32:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E117B1A5BE15; Mon, 12 Sep 2011 14:32:41 +0200 (CEST) Date: Mon, 12 Sep 2011 14:32:41 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20110912123241.GD39925@elstar.local> Mail-Followup-To: Phil Shafer , Martin Bjorklund , netmod@ietf.org References: <20110911.193211.254882919.mbj@tail-f.com> <201109121143.p8CBhOxN039389@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109121143.p8CBhOxN039389@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 12:30:52 -0000 On Mon, Sep 12, 2011 at 07:43:24AM -0400, Phil Shafer wrote: > Martin Bjorklund writes: > >As Juergen stated, the "problem" (I am not convinced this is a real > >problem) only occurs if you do config via SNMP, and backup/restore > >over NETCONF. If this is not common, should we really solve it? > > So we define rows where RowStatus isn't active as non-configuration > data, just a "work space" for SNMP. In the same way one can't > backup/restore invalid configs built inside the candidate database > (that would fail any commit operations), one can't backup/restore > the snmp work space. > > This means that activating the row makes it become configuration > data, and deactivating the row makes it become non-config data > again. > > Hmmm.... perhaps this resembles the "inactive" configuration we > support in JUNOS, where a hierarchy of configuration data can be > deactivated, essentially commenting it out of the data we expose > to JUNOS subcomponents, while keeping the data in the configuration > database. See CLI session transcript below (where deactivating > netconf removes it from inetd.conf and activating it restores it). > Inactive config is marked with "inactive:" in the CLI and with the > "inactive" attribute in XML. I do not think RowStatus is a challenge since all states other than `active' are transient. In particular, RFC 2579 says: - `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; Assuming proper usage of RowStatus, rows that are not 'active' can IMHO safely be ignored. But I think RowStatus was not really the issue that got us here. I believe we started from the question whether the YANG data model for configuring SNMP has to support things like dangling references that are possible to have in the SNMP tables and whether it has to support configurations that might be legal to have in SNMP tables but that are not useful operationally. My feeling was that we likely have to sort this out on a case by case basis. And all this is likely coupled with the underlying question whether we assume there is an SNMP speaking manager creating SNMP configurations and a NETCONF manager is merely providing a secondary interface or we assume a NETCONF manager is the primary configuration interface and what is being created by NETCONF must be properly represented in the SNMP tables so SNMP speaking managers can understand the configuration (can carry out certain functions such as key changes etc.). Randy most likely says both must be equally be possible - and I agree except that the devel is in the details. /js (as contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Sep 12 05:50:05 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AFD21F8B1C for ; Mon, 12 Sep 2011 05:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kex52VEY3C61 for ; Mon, 12 Sep 2011 05:50:04 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A617821F8B22 for ; Mon, 12 Sep 2011 05:50:04 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2EAEB1200D16; Mon, 12 Sep 2011 14:46:41 +0200 (CEST) Date: Mon, 12 Sep 2011 14:52:01 +0200 (CEST) Message-Id: <20110912.145201.1428011339355999039.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110912123241.GD39925@elstar.local> References: <20110911.193211.254882919.mbj@tail-f.com> <201109121143.p8CBhOxN039389@idle.juniper.net> <20110912123241.GD39925@elstar.local> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 12:50:05 -0000 Hi, Juergen Schoenwaelder wrote: > But I think RowStatus was not really the issue that got us here. I > believe we started from the question whether the YANG data model for > configuring SNMP has to support things like dangling references that > are possible to have in the SNMP tables and whether it has to support > configurations that might be legal to have in SNMP tables but that are > not useful operationally. My feeling was that we likely have to sort > this out on a case by case basis. If we had Phil's inactive support in NETCONF, we could support these dangling references, by marking a node with a dangling reference as 'inactive'. This is very neat. Unfortunately, 'inactive' is not standardized :( /martin From j.schoenwaelder@jacobs-university.de Mon Sep 12 06:21:48 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4EF21F8B0B for ; Mon, 12 Sep 2011 06:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.111 X-Spam-Level: X-Spam-Status: No, score=-103.111 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8K4AuJ051bg for ; Mon, 12 Sep 2011 06:21:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C154721F86EE for ; Mon, 12 Sep 2011 06:21:47 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6E8E20CEF; Mon, 12 Sep 2011 15:23:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 869ztZ8oiJwJ; Mon, 12 Sep 2011 15:23:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 76ED820CED; Mon, 12 Sep 2011 15:23:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 95EEF1A5C0F3; Mon, 12 Sep 2011 15:23:37 +0200 (CEST) Date: Mon, 12 Sep 2011 15:23:37 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110912132337.GB40443@elstar.local> Mail-Followup-To: Martin Bjorklund , phil@juniper.net, netmod@ietf.org References: <20110911.193211.254882919.mbj@tail-f.com> <201109121143.p8CBhOxN039389@idle.juniper.net> <20110912123241.GD39925@elstar.local> <20110912.145201.1428011339355999039.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110912.145201.1428011339355999039.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 13:21:48 -0000 On Mon, Sep 12, 2011 at 02:52:01PM +0200, Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: > > But I think RowStatus was not really the issue that got us here. I > > believe we started from the question whether the YANG data model for > > configuring SNMP has to support things like dangling references that > > are possible to have in the SNMP tables and whether it has to support > > configurations that might be legal to have in SNMP tables but that are > > not useful operationally. My feeling was that we likely have to sort > > this out on a case by case basis. > > If we had Phil's inactive support in NETCONF, we could support these > dangling references, by marking a node with a dangling reference as > 'inactive'. This is very neat. Unfortunately, 'inactive' is not > standardized :( I guess Randy would argue that they are active, just not used at the moment. For example, an access control policy might be active but simply not used until an SNMP over SSH sessions comes in with a RADIUS provisioned mapping to a group name that suddenly makes use of the "dangling" access control policy. OK, this example is kind of constructed and the YANG data model does not seem to have a problem here. We started from the leafref requirement for some nodes where there is no requirement that stuff points to existing other stuff in SNMP land. For example, the vacmAccessReadViewName may be arbitrary nonsense but YANG says it should be a leafref, that is, it requires consistency where SNMP does not require it. One option, of course, is to give up this consistency requirement such that the YANG model can represent SNMP configurations that happen to have unused references or references in non-existing definitions. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Sep 12 06:37:22 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F94F21F8B1A for ; Mon, 12 Sep 2011 06:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jCK0SncVbfz for ; Mon, 12 Sep 2011 06:37:22 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 02ECB21F8B10 for ; Mon, 12 Sep 2011 06:37:21 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 335C91200D16; Mon, 12 Sep 2011 15:34:04 +0200 (CEST) Date: Mon, 12 Sep 2011 15:39:23 +0200 (CEST) Message-Id: <20110912.153923.2183365773276001319.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110912132337.GB40443@elstar.local> References: <20110912123241.GD39925@elstar.local> <20110912.145201.1428011339355999039.mbj@tail-f.com> <20110912132337.GB40443@elstar.local> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 13:37:22 -0000 Juergen Schoenwaelder wrote: > We started from the leafref requirement for some nodes where there is > no requirement that stuff points to existing other stuff in SNMP > land. For example, the vacmAccessReadViewName may be arbitrary > nonsense but YANG says it should be a leafref, that is, it requires > consistency where SNMP does not require it. One option, of course, is > to give up this consistency requirement such that the YANG model can > represent SNMP configurations that happen to have unused references or > references in non-existing definitions. Yes, for leafrefs this is trivial to change - just don't use a leafref. My concern is that these dangling references makes the solution more error prone. A typo in e.g. a vacmAccessReadViewName will go undetected. But for other "valid" configurations it is not that easy. For example the mp/security model combination I mentioned earlier: snmpTargetParamsMPModel = 0 snmpTargetParamsSecurityModel = 3 With the proposed YANG model, this cannot be represented. (Maybe we can have a catch-all 'case' in the YANG model: case non-sense-config { leaf snmpTargetParamsMPModel { ... } leaf snmpTargetParamsSecurityModel { ... } ... } ) /martin From wjhns1@hardakers.net Mon Sep 12 07:46:58 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC1321F8696 for ; Mon, 12 Sep 2011 07:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bycT0Yg7VArq for ; Mon, 12 Sep 2011 07:46:58 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7772C21F8B14 for ; Mon, 12 Sep 2011 07:46:57 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 39FC423F; Mon, 12 Sep 2011 07:48:29 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" References: <001301cc6f14$d12fc6a0$6801a8c0@oemcomputer> <20110909213045.GA35891@elstar.local> <000401cc6f3d$8ef04160$6801a8c0@oemcomputer> <20110911.193211.254882919.mbj@tail-f.com> <001101cc70f1$ef7a4a20$6801a8c0@oemcomputer> Date: Mon, 12 Sep 2011 07:48:29 -0700 In-Reply-To: <001101cc70f1$ef7a4a20$6801a8c0@oemcomputer> (Randy Presuhn's message of "Sun, 11 Sep 2011 19:16:07 -0700") Message-ID: User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 14:46:58 -0000 >>>>> On Sun, 11 Sep 2011 19:16:07 -0700, "Randy Presuhn" said: RP> "this problem"? RP> At least three distinct problems have been brought up in this RP> thread. ... FYI, I'm at the "+1 to everything Randy has said" point, as his arguments are sound and reflect the reality of what exists is the current world, whether or not NETCONF wants it to be there. Rows *do* exist in SNMP tables where the values have dangling references. I see them all the time, and they're there by intention (and the mention of the dangling VACM reference waiting for a RADIUS connection is a good example, but even more to the point: I've seen administrators leave references in tables dangling because they want to use it as a "flip the switch when I need it by adding the missing row when i want it active"). I've also seen lots of cases where internally to the software the SNMP table isn't the complete set of config: it's simply the closest they could do to expose parts of the config that exist in SNMP tables. There are other bits laying around in private-data/internal-config that are either not exposed because there is no MIB objects to expose them in, or because they're intentionally hidden because the vendor wants those config bits to be proprietary (a situation I hate, but they do exist to create vendor-lock-in). I've seen cases of rows being marked and created as permanent because they're created internally but are exposed in part to allow at least some run-time configuration. The problem is that netconf's "copy" really isn't designed to handle cases like this. Especially when the row references change (eg, the ifIndex of the two devices swap on reboot (yes, I know they shouldn't; but they do in many implementations)). I've also seen vendors use "special values" to get around creating their own private MIBs to house special data in. And the MPModel = 0, securityModel = 3 is exactly those types of cases where "because it'll never exist in the standards world, why don't we just reuse that weird combination to do something special internal". Yes, every time someone asks me if that's ok I do tell them "no". But unfortunately, not everyone asks and not everyone listens to the responses they get. So, I'm sure many people who made it this far into my text are saying "yes, but half of that argument is about illegal values or values that shouldn't exist in that combination". Sure, you're partially right. Many things shouldn't exist, but often do anyway. The real question is: until NETCONF achieves market dominance, will you succeed when you approach a widget, be it an SNMP agent or other object needing config, and say "we have this great new technology for sending configuration data around, but it'll require you to limit yourself and stop your code and your customers from doing what they're doing at the moment." Until NETCONF is the elephant that everyone wants, I don't see this argument succeeding. More specifically to my particular case: if someone proposed a allow-NETCONF-config patch to Net-SNMP and wanted it incorporated but it meant that it'd wipe out all the dangling VACM references and would fail to work with any permanent rows, I'd be flamed if I tried to propose accepting it. But your SNMP configuration example is but the beginning. In some sense it's a bad one to start with because of the potential perception of competing-technologies that may appear to be the root cause (but really isn't). If you try to do similar things with any other highly-different internal models you're likely to run into similar problems. EG, configuring firewalls (where permanent rows are common) from 4 different vendors will likely have the same problem: the models may not act the way you want them to in an ideal world. NETCONF needs to make the technology it's trying to instrument easier to configure without making imposing restrictions on it. It's up to the underlying model to define the restrictions, *not* the configuration protocol. Yes, this likely means you'll end up with yang models that are not as restrictive or clean as you'd like. -- Wes Hardaker SPARTA, Inc. From j.schoenwaelder@jacobs-university.de Mon Sep 12 08:36:26 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A47021F8713 for ; Mon, 12 Sep 2011 08:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.113 X-Spam-Level: X-Spam-Status: No, score=-103.113 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wntfc3GQdVpb for ; Mon, 12 Sep 2011 08:36:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BBBD321F854E for ; Mon, 12 Sep 2011 08:36:25 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D9BC20D3A; Mon, 12 Sep 2011 17:38:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TLgD5Tl+-MUC; Mon, 12 Sep 2011 17:38:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BEF3420D36; Mon, 12 Sep 2011 17:38:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EEB1A1A5C5C3; Mon, 12 Sep 2011 17:38:16 +0200 (CEST) Date: Mon, 12 Sep 2011 17:38:16 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110912153816.GC41241@elstar.local> Mail-Followup-To: Martin Bjorklund , phil@juniper.net, netmod@ietf.org References: <20110912123241.GD39925@elstar.local> <20110912.145201.1428011339355999039.mbj@tail-f.com> <20110912132337.GB40443@elstar.local> <20110912.153923.2183365773276001319.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110912.153923.2183365773276001319.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 15:36:26 -0000 On Mon, Sep 12, 2011 at 03:39:23PM +0200, Martin Bjorklund wrote: > But for other "valid" configurations it is not that easy. For example > the mp/security model combination I mentioned earlier: > > snmpTargetParamsMPModel = 0 > snmpTargetParamsSecurityModel = 3 > > With the proposed YANG model, this cannot be represented. For me personally, this is clearly an example of a configuration that is never ever meaningful. If this fails the backup/restore test, fine. The description of snmpTargetParamsSecurityModel is really interesting: snmpTargetParamsSecurityModel OBJECT-TYPE SYNTAX SnmpSecurityModel (1..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The Security Model to be used when generating SNMP messages using this entry. An implementation may choose to return an inconsistentValue error if an attempt is made to set this variable to a value for a security model which the implementation does not support." ::= { snmpTargetParamsEntry 3 } I love this "may choose to return an inconsistentValue error" phrase. So apparently an implementation can be compliant by accepting snmpTargetParamsMPModel = 0 snmpTargetParamsSecurityModel = 3 and in the best case your agent drops this target when trying to send a message or in the worst case your agent just dies. Would be interesting to try how existing agents handle this and how many survive. ;-) Someone previously asked for an example of a non-meaningful configuration. For me, this is such an example. /js (as contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Sep 12 09:56:34 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0330D21F8BBB for ; Mon, 12 Sep 2011 09:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWnlFNBXDw-h for ; Mon, 12 Sep 2011 09:56:33 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 800F521F8C1D for ; Mon, 12 Sep 2011 09:56:13 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 3DD0E1200CFE; Mon, 12 Sep 2011 18:52:53 +0200 (CEST) Date: Mon, 12 Sep 2011 18:58:14 +0200 (CEST) Message-Id: <20110912.185814.299792698.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110912082303.GB39270@elstar.local> References: <20110909213045.GA35891@elstar.local> <000401cc6f3d$8ef04160$6801a8c0@oemcomputer> <20110912082303.GB39270@elstar.local> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 16:56:34 -0000 Juergen Schoenwaelder wrote: > As a matter of fact, there are a number of CLIs for configuration of > SNMP and it seems there is a certain number of networks where SNMP > configuration via interfaces other than SNMP seems attractive. Perhaps > the goal of this work is not backup/restore of a configuration done > via SNMP but instead configuration and backup/restore via NETCONF but > with proper representation to SNMP managers. Does that make sense? Yes, I think this makes sense. What would the charter text be to cover this? /martin From randy_presuhn@mindspring.com Mon Sep 12 11:15:52 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C853B21F8B25 for ; Mon, 12 Sep 2011 11:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.068 X-Spam-Level: X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od7yyMdp4rdy for ; Mon, 12 Sep 2011 11:15:52 -0700 (PDT) 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 048D621F8B15 for ; Mon, 12 Sep 2011 11:15:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=E/Hytn14BnwQxIkzBdwv4j7DeacMkmxXoI0d7tziHNs9+qqvYR+C/rZZV922qLzX; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.55.84] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R3B4r-0005qV-Bk for netmod@ietf.org; Mon, 12 Sep 2011 14:17:53 -0400 Message-ID: <002001cc7178$5db8ad20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000401cc6e4c$ae279020$6801a8c0@oemcomputer> <20110908.221407.473194402.mbj@tail-f.com> <001201cc6e9b$3b2a0ea0$6801a8c0@oemcomputer> <20110909.093333.329504282.mbj@tail-f.com> <001301cc6f14$d12fc6a0$6801a8c0@oemcomputer> <20110909213045.GA35891@elstar.local> <000401cc6f3d$8ef04160$6801a8c0@oemcomputer> <20110912082303.GB39270@elstar.local> Date: Mon, 12 Sep 2011 11:18:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee28818787ec5098f3c493703b3e88aeca640350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.55.84 Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 18:15:52 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Monday, September 12, 2011 1:23 AM > Subject: Re: [netmod] snmp configuration data model charter addition ... > So can we conclude that unless an application configured a box via > SNMP in the first place, a proper backup/restore of SNMPv3 > configuration is in general not possible even with SNMP? No. The "unless" condition you propose is neither necessary nor sufficient. In that particular set of pathological cases, the conflict arises due to the potential for incompatibilities between "hard-wired" portions of the configuration data on different boxes that are nonetheless sufficiently similar for configuration portability to be desirable. There are heuristic work-arounds, but once one reaches the limits of those heuristics, I think the conclusion has to be "don't do that", as the things being configured aren't sufficiently similar to support the management objective. > As a matter of fact, there are a number of CLIs for configuration of > SNMP and it seems there is a certain number of networks where SNMP > configuration via interfaces other than SNMP seems attractive. Perhaps > the goal of this work is not backup/restore of a configuration done > via SNMP but instead configuration and backup/restore via NETCONF but > with proper representation to SNMP managers. Does that make sense? It is plausible, but I still object to the idea of introducing gratuitous incompatibilities into the data models. In any case where the semantics or constraints in the YANG model are different from the SMI, there should be an explicit statement of why the incompatibility is necessary and desirable. Randy From randy_presuhn@mindspring.com Mon Sep 12 12:33:05 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6840621F8CC6 for ; Mon, 12 Sep 2011 12:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZA9vP89NWlZ1 for ; Mon, 12 Sep 2011 12:33:05 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id D71D521F8CB4 for ; Mon, 12 Sep 2011 12:33:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=smTEHa7s3E7+G25+pNSq/4gt8AdBdQ257M5JIoLG5NnYjgmLjgvDjbDnWEqV8NUM; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.55.84] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R3CHY-0008Ii-B7 for netmod@ietf.org; Mon, 12 Sep 2011 15:35:04 -0400 Message-ID: <009f01cc7183$263ba7c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20110909213045.GA35891@elstar.local><000401cc6f3d$8ef04160$6801a8c0@oemcomputer><20110912082303.GB39270@elstar.local> <20110912.185814.299792698.mbj@tail-f.com> Date: Mon, 12 Sep 2011 12:35:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee288d9e422d3b5a2eb717e8af2ef66a94780350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.55.84 Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 19:33:05 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: ; > Sent: Monday, September 12, 2011 9:58 AM > Subject: Re: [netmod] snmp configuration data model charter addition > > Juergen Schoenwaelder wrote: > > As a matter of fact, there are a number of CLIs for configuration of > > SNMP and it seems there is a certain number of networks where SNMP > > configuration via interfaces other than SNMP seems attractive. Perhaps > > the goal of this work is not backup/restore of a configuration done > > via SNMP but instead configuration and backup/restore via NETCONF but > > with proper representation to SNMP managers. Does that make sense? > > Yes, I think this makes sense. What would the charter text be to > cover this? If folks really want to do this, perhaps something like this might serve as a rough starting point: The YANG models MUST NOT permit configurations the corresponding SMI models would be unable to represent. The YANG models MAY be more restrictive than the SMI models, but MUST explicitly document why such incompatibilities are necessary and desirable, and spell out what happens when NETCONF is used to attempt to retrieve, modify, or replace portions of a configuration which the SMI can represent but which the YANG models for any reason reject. Randy From mbj@tail-f.com Wed Sep 14 06:07:08 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9A621F8B55 for ; Wed, 14 Sep 2011 06:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePf1NOqJM-g1 for ; Wed, 14 Sep 2011 06:07:07 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 873B121F8A4E for ; Wed, 14 Sep 2011 06:07:07 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3FB531200039; Wed, 14 Sep 2011 15:03:43 +0200 (CEST) Date: Wed, 14 Sep 2011 15:09:12 +0200 (CEST) Message-Id: <20110914.150912.2101383925779919702.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <009f01cc7183$263ba7c0$6801a8c0@oemcomputer> References: <20110912082303.GB39270@elstar.local> <20110912.185814.299792698.mbj@tail-f.com> <009f01cc7183$263ba7c0$6801a8c0@oemcomputer> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 13:07:08 -0000 Hi, "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: ; > > Sent: Monday, September 12, 2011 9:58 AM > > Subject: Re: [netmod] snmp configuration data model charter addition > > > > Juergen Schoenwaelder wrote: > > > As a matter of fact, there are a number of CLIs for configuration of > > > SNMP and it seems there is a certain number of networks where SNMP > > > configuration via interfaces other than SNMP seems attractive. Perhaps > > > the goal of this work is not backup/restore of a configuration done > > > via SNMP but instead configuration and backup/restore via NETCONF but > > > with proper representation to SNMP managers. Does that make sense? > > > > Yes, I think this makes sense. What would the charter text be to > > cover this? > > If folks really want to do this, perhaps something like this might serve > as a rough starting point: > > The YANG models MUST NOT permit configurations the > corresponding SMI models would be unable to represent. Actually, we do want to cover some things not present in the MIBs, e.g., the listen address(es). > The YANG models MAY be more restrictive than the SMI models, > but MUST explicitly document why such incompatibilities are > necessary and desirable, and spell out what happens when > NETCONF is used to attempt to retrieve, modify, or replace portions > of a configuration which the SMI can represent but which the > YANG models for any reason reject. I don't disagree with the meaning of this text, but maybe it is a bit too detailed for a charter? Actually, I think the underlying meaning of this text is covered by Juergen's proposed text: Data model for configuring SNMP engines. The model must be capable of representing all meaningful SNMP engine configurations possible with the standard SNMPv3 MIB modules. In the WG, we need to make sure that we clearly spell out the mapping, and that any difference in the data model is documented. /martin From randy_presuhn@mindspring.com Wed Sep 14 09:34:40 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348C021F8AFE for ; Wed, 14 Sep 2011 09:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.335 X-Spam-Level: X-Spam-Status: No, score=-101.335 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAGLfgsL3wFt for ; Wed, 14 Sep 2011 09:34:39 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id C0F1721F8ABB for ; Wed, 14 Sep 2011 09:34:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=t6H3kvRThJb2KfusErIRkjJSV2GbwkGOlNeGsVgxbIPvlSTG2jdHFXEwViE1yn0m; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.224.165] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R3sS3-0003lM-NW for netmod@ietf.org; Wed, 14 Sep 2011 12:36:44 -0400 Message-ID: <001201cc72fc$91edaf20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20110912082303.GB39270@elstar.local><20110912.185814.299792698.mbj@tail-f.com><009f01cc7183$263ba7c0$6801a8c0@oemcomputer> <20110914.150912.2101383925779919702.mbj@tail-f.com> Date: Wed, 14 Sep 2011 09:37:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee288a4736e4549814d66b09f531618ea2bf8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.224.165 Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 16:34:40 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Wednesday, September 14, 2011 6:09 AM > Subject: Re: [netmod] snmp configuration data model charter addition ... > > The YANG models MUST NOT permit configurations the > > corresponding SMI models would be unable to represent. > > Actually, we do want to cover some things not present in the MIBs, > e.g., the listen address(es). The only way I could support this would be if the scope of the work explicitly included an update to the MIBs to add any such information. I think that creating a situation where *neither* protocol is able to operate on the complete configuration is a recipe for disaster, and should be carefully avoided. If such information is added, it should also be acompanied by updates to RFC 3411, 3412, 3413, RFC 2741, and possibly RFC 1227, since changes to things like listen addresses need to be carefully serialized with the elements of procedure in these documents. > > The YANG models MAY be more restrictive than the SMI models, > > but MUST explicitly document why such incompatibilities are > > necessary and desirable, and spell out what happens when > > NETCONF is used to attempt to retrieve, modify, or replace portions > > of a configuration which the SMI can represent but which the > > YANG models for any reason reject. > > I don't disagree with the meaning of this text, but maybe it is a bit > too detailed for a charter? Actually, I think the underlying meaning > of this text is covered by Juergen's proposed text: > > Data model for configuring SNMP engines. The model must be > capable of representing all meaningful SNMP engine > configurations possible with the standard SNMPv3 MIB modules. > > In the WG, we need to make sure that we clearly spell out the mapping, > and that any difference in the data model is documented. I still have a huge problem with "meaningful". It's far too loose, and, as Wes has spelled out, the I-D demonstrates that it already has been understood in ways that are at odds with both the design of the MIBs and with common operational practice. But this discussion seems to be looping, so I think I'll bail for now. Randy From j.schoenwaelder@jacobs-university.de Wed Sep 14 12:59:10 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4E721F8BA8 for ; Wed, 14 Sep 2011 12:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.118 X-Spam-Level: X-Spam-Status: No, score=-103.118 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lv9S8GAAscMN for ; Wed, 14 Sep 2011 12:59:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 53ED721F8B9F for ; Wed, 14 Sep 2011 12:59:09 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A7AE20E33; Wed, 14 Sep 2011 22:01:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id c6OGGiJBd08c; Wed, 14 Sep 2011 22:01:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8820620DF1; Wed, 14 Sep 2011 22:01:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DA4301A64F6A; Wed, 14 Sep 2011 22:01:03 +0200 (CEST) Date: Wed, 14 Sep 2011 22:01:03 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20110914200101.GB7073@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <20110912082303.GB39270@elstar.local> <20110912.185814.299792698.mbj@tail-f.com> <009f01cc7183$263ba7c0$6801a8c0@oemcomputer> <20110914.150912.2101383925779919702.mbj@tail-f.com> <001201cc72fc$91edaf20$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201cc72fc$91edaf20$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 19:59:10 -0000 On Wed, Sep 14, 2011 at 09:37:17AM -0700, Randy Presuhn wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Wednesday, September 14, 2011 6:09 AM > > Subject: Re: [netmod] snmp configuration data model charter addition > ... > > > The YANG models MUST NOT permit configurations the > > > corresponding SMI models would be unable to represent. > > > > Actually, we do want to cover some things not present in the MIBs, > > e.g., the listen address(es). > > The only way I could support this would be if the scope of the work > explicitly included an update to the MIBs to add any such information. > I think that creating a situation where *neither* protocol is able to > operate on the complete configuration is a recipe for disaster, > and should be carefully avoided. > > If such information is added, it should also be acompanied by updates > to RFC 3411, 3412, 3413, RFC 2741, and possibly RFC 1227, since > changes to things like listen addresses need to be carefully serialized > with the elements of procedure in these documents. Pretty much all SNMP agents I have seen allow to configure the port they are listening on. Yes, there is no MIB interface to do this. This situation is out there for +20 years. Are you saying we have to keep this situation or first define MIB modules in order to do what proprietary configuration interfaces already provide for +20 years? > > > The YANG models MAY be more restrictive than the SMI models, > > > but MUST explicitly document why such incompatibilities are > > > necessary and desirable, and spell out what happens when > > > NETCONF is used to attempt to retrieve, modify, or replace portions > > > of a configuration which the SMI can represent but which the > > > YANG models for any reason reject. > > > > I don't disagree with the meaning of this text, but maybe it is a bit > > too detailed for a charter? Actually, I think the underlying meaning > > of this text is covered by Juergen's proposed text: > > > > Data model for configuring SNMP engines. The model must be > > capable of representing all meaningful SNMP engine > > configurations possible with the standard SNMPv3 MIB modules. > > > > In the WG, we need to make sure that we clearly spell out the mapping, > > and that any difference in the data model is documented. > > I still have a huge problem with "meaningful". It's far too loose, and, as > Wes has spelled out, the I-D demonstrates that it already has been > understood in ways that are at odds with both the design of the MIBs > and with common operational practice. > > But this discussion seems to be looping, so I think I'll bail for now. The devil is in the details. Apparently, the MIB modules allow to configure SNMPv1 with USM. This never ever works. So is it really useful to allow this in a YANG configuration data model, given that even the MIB module allows agents to reject this (but does not require this)? I am in favour of going through the details where there are differences instead of adopting general rules. /js (speaking as contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Wed Sep 14 18:01:45 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C33B21F87FC for ; Wed, 14 Sep 2011 18:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.186 X-Spam-Level: X-Spam-Status: No, score=-102.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyo2oU5pTdv3 for ; Wed, 14 Sep 2011 18:01:44 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEBA21F87FA for ; Wed, 14 Sep 2011 18:01:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gMW6VsFsxCsTYtmupwdvzTItl4obvMsnvR+g86lpOBqOh7bZnHG46eC6mdiqFYEG; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.50.145] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R40Mo-0000CF-7g for netmod@ietf.org; Wed, 14 Sep 2011 21:03:50 -0400 Message-ID: <001e01cc7343$6a9a4540$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20110912082303.GB39270@elstar.local> <20110912.185814.299792698.mbj@tail-f.com> <009f01cc7183$263ba7c0$6801a8c0@oemcomputer> <20110914.150912.2101383925779919702.mbj@tail-f.com> <001201cc72fc$91edaf20$6801a8c0@oemcomputer> <20110914200101.GB7073@elstar.local> Date: Wed, 14 Sep 2011 18:04:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee2884c0565fc8f6b478aacd698de1d5894d2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.50.145 Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 01:01:45 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, September 14, 2011 1:01 PM > Subject: Re: [netmod] snmp configuration data model charter addition .... > Pretty much all SNMP agents I have seen allow to configure the port > they are listening on. Yes, there is no MIB interface to do this. This > situation is out there for +20 years. Are you saying we have to keep > this situation or first define MIB modules in order to do what > proprietary configuration interfaces already provide for +20 years? What I'm saying is that if the opposition to standardization of this capability has finally gone away after all these years, (alleluia!) that to do it right, we should be able to do it via a standards-track MIB interface. .... > The devil is in the details. Apparently, the MIB modules allow to > configure SNMPv1 with USM. This never ever works. So is it really > useful to allow this in a YANG configuration data model, given that > even the MIB module allows agents to reject this (but does not require > this)? I am in favour of going through the details where there are > differences instead of adopting general rules. Whether such a combination is rejected or not is implementation-specific, and as an implementation-specific behaviour, using the model to bless one implementation while damning another seems like inappropriate over-engineering, if not outright anti-competitive behaviour. Since I'm no longer in the business (and the code with which I am most familiar would probably reject such a setting as an inconsistant value) I don't really care that much, other than to say this still seems rather unwise. I'd be less concerned if the implementors of today's widely deployed code bases were all saying this won't be a problem, and were all willing to check against their respective code bases any incompatibilities the WG decided to add or inadvertantly allowed to creep in. The SNMP engine people I've seen in this dicussion (Wes, David Reid, and myself) might be considered "old guard" due to our association with rather mature code bases, and that might also explain our lack of support for adding incompatibilies. Are there some other folks from the SNMP engine room, perhaps of more recent vintage, who could speak up, pro or con? Randy From j.schoenwaelder@jacobs-university.de Wed Sep 14 23:01:42 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7520621F8610 for ; Wed, 14 Sep 2011 23:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.119 X-Spam-Level: X-Spam-Status: No, score=-103.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0F0Z5FNeDLs for ; Wed, 14 Sep 2011 23:01:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 68D7F21F85AA for ; Wed, 14 Sep 2011 23:01:41 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8D3F20E72; Thu, 15 Sep 2011 08:03:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id c6iIW77OlxuL; Thu, 15 Sep 2011 08:03:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D03A420E6B; Thu, 15 Sep 2011 08:03:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 44A181A96170; Thu, 15 Sep 2011 08:03:37 +0200 (CEST) Date: Thu, 15 Sep 2011 08:03:36 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20110915060336.GA33798@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <20110912082303.GB39270@elstar.local> <20110912.185814.299792698.mbj@tail-f.com> <009f01cc7183$263ba7c0$6801a8c0@oemcomputer> <20110914.150912.2101383925779919702.mbj@tail-f.com> <001201cc72fc$91edaf20$6801a8c0@oemcomputer> <20110914200101.GB7073@elstar.local> <001e01cc7343$6a9a4540$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001e01cc7343$6a9a4540$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] snmp configuration data model charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 06:01:42 -0000 On Wed, Sep 14, 2011 at 06:04:26PM -0700, Randy Presuhn wrote: > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Randy Presuhn" > > Cc: > > Sent: Wednesday, September 14, 2011 1:01 PM > > Subject: Re: [netmod] snmp configuration data model charter addition > .... > > Pretty much all SNMP agents I have seen allow to configure the port > > they are listening on. Yes, there is no MIB interface to do this. This > > situation is out there for +20 years. Are you saying we have to keep > > this situation or first define MIB modules in order to do what > > proprietary configuration interfaces already provide for +20 years? > > What I'm saying is that if the opposition to standardization of this > capability has finally gone away after all these years, (alleluia!) > that to do it right, we should be able to do it via a standards-track > MIB interface. I believe this is a separate issue to discuss and I am not even sure whether you scope this "requirement" just to SNMP engine configuration or even want this in more general. As a matter of fact, CLIs on most devices cover configuration knobs MIB modules do not cover, see also the discussions back when RFC 3535 was created. > I'd be less concerned if the implementors of today's widely deployed code > bases were all saying this won't be a problem, and were all willing to check > against their respective code bases any incompatibilities the WG decided > to add or inadvertantly allowed to creep in. The SNMP engine people I've > seen in this dicussion (Wes, David Reid, and myself) might be considered > "old guard" due to our association with rather mature code bases, and that > might also explain our lack of support for adding incompatibilies. Are > there some other folks from the SNMP engine room, perhaps of more recent > vintage, who could speak up, pro or con? As far as I know, the YANG module in the I-D (which surely will chance and likely to reduce differences, e.g. making the leafrefs just ordinary strings is not a big deal) has been reviewed and discussed privately with people from large SNMP engine suppliers to find out whether there are any issues with their code base. And this is what needs to continue in the WG if this work becomes a WG work item and I understood that David Reid is going to do that for one SNMP engine supplier. Wes' statement is not clear to me since he also kind of said any combination of legal or illegal values might be overloaded with other semantics and I do not know how to deal with that. That said, more input to the discussion at this point in time would be very useful, both from SNMP engine folks but also from operators that configure today's SNMP engines. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Sep 18 14:27:56 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B3921F8997 for ; Sun, 18 Sep 2011 14:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crqR3DnYPQbb for ; Sun, 18 Sep 2011 14:27:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id F36DB21F8672 for ; Sun, 18 Sep 2011 14:27:54 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5AA4020D11 for ; Sun, 18 Sep 2011 23:30:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kE5QF8mCDKdq for ; Sun, 18 Sep 2011 23:30:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A320720D0A for ; Sun, 18 Sep 2011 23:30:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A3AA51AEE42B; Sun, 18 Sep 2011 23:29:59 +0200 (CEST) Resent-From: Juergen Schoenwaelder Resent-Date: Sun, 18 Sep 2011 23:29:59 +0200 Resent-Message-ID: <20110918212959.GB1097@elstar.local> Resent-To: netmod@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS04.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server id 14.1.323.3; Sun, 18 Sep 2011 11:59:25 +0200 Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EEBA20E7F for ; Sun, 18 Sep 2011 11:59:26 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by atlas2.jacobs-university.de (Postfix) with ESMTP id 0450226A for ; Sun, 18 Sep 2011 11:59:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas2a.jacobs-university.de ([212.201.44.15]) by localhost (demetrius3.jacobs-university.de [212.201.44.48]) (amavisd-new, port 10030) with ESMTP id QXqpLFaBlXf3 for ; Sun, 18 Sep 2011 11:59:23 +0200 (CEST) X-Greylist: delayed 2145 seconds by postgrey-1.32 at atlas2; Sun, 18 Sep 2011 11:59:23 CEST X-JacobsISPWhiteListed: med ietf.org DNSWLId 1703 Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by atlas2a.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 18 Sep 2011 11:59:23 +0200 (CEST) Received: from mail.ietf.org ([2001:1890:123a::1:1e]:53884) by merlot.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1R5DZw-0003kq-9N for ops-chairs@tools.ietf.org; Sun, 18 Sep 2011 11:22:25 +0200 Received: by ietfa.amsl.com (Postfix, from userid 65534) id 71FE421F8509; Sun, 18 Sep 2011 02:19:58 -0700 (PDT) X-Original-To: tools-ops-chairs@ietfa.amsl.com Delivered-To: tools-ops-chairs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422FF21F84D5 for ; Sun, 18 Sep 2011 02:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMlUtDYwOTTo for ; Sun, 18 Sep 2011 02:19:57 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id EB73321F8507 for ; Sun, 18 Sep 2011 02:19:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQAAG63dU7GmAcF/2dsb2JhbABChFWTdI1wgQ53gVMBAQEBAwEBAQ8KAQYNPhcGAQgNBAQBAQsGBgEBBAgDAQICAwElHwcBAQUEAQQTCAwOh1mWM4QMAolTkDSDbAEEB4FvMWAEjjWKUItz X-IronPort-AV: E=Sophos;i="4.68,400,1312171200"; d="txt'?scan'208";a="268384437" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Sep 2011 05:22:13 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Sep 2011 05:21:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC75E4.72B1F984" Date: Sun, 18 Sep 2011 11:22:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom 2011-2012: Second Call for Nominations Thread-Index: Acx1p9u3AWkVzVcyQKWo5Y9L5tyddgAOnvKw From: "Romascanu, Dan (Dan)" To: X-SA-Exim-Connect-IP: 2001:1890:123a::1:1e X-SA-Exim-Rcpt-To: ops-chairs@tools.ietf.org X-SA-Exim-Mail-From: dromasca@avaya.com X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) X-MS-Exchange-Organization-AuthSource: SHUBCAS04.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 Subject: [netmod] FW: Nomcom 2011-2012: Second Call for Nominations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 21:27:56 -0000 ------_=_NextPart_001_01CC75E4.72B1F984 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSBPUFMgY2hhaXJzLA0KDQpQbGVhc2UgZGlzdHJpYnV0ZSB0aGlzIGZ1cnRoZXIgdG8geW91 ciB3b3JraW5nIGdyb3Vwcy4gUHJvcG9zaW5nIHRoZSBiZXN0IGNhbmRpZGF0ZXMgZm9yIHRoZSBv cGVuIHBvc2l0aW9ucyBpbiB0aGUgSUVURiBsZWFkZXJzaGlwIGFuZCBzdXBwb3J0aW5nIE5vbUNv bSB3aXRoIHlvdXIgY29tbWVudHMgYWJvdXQgdGhlIGNhbmRpZGF0ZXMgYW5kIHByb3Bvc2FscyBp cyBvZiBncmVhdCBpbXBvcnRhbmNlIGZvciB0aGUgSUVURi4gDQoNClRoYW5rcyBhbmQgUmVnYXJk cywNCg0KRGFuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWV0Zi1h bm5vdW5jZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgTm9tQ29tIENoYWlyDQpTZW50OiBTdW5kYXksIFNlcHRlbWJl ciAxOCwgMjAxMSA1OjA2IEFNDQpUbzogSUVURiBBbm5vdW5jZW1lbnQgbGlzdA0KQ2M6IGlldGZA aWV0Zi5vcmcNClN1YmplY3Q6IE5vbWNvbSAyMDExLTIwMTI6IFNlY29uZCBDYWxsIGZvciBOb21p bmF0aW9ucyANCg0KSGkgQWxsLA0KDQpXZSBhcmUgaGFsZndheSB0aHJvdWdoIHRoZSBub21pbmF0 aW9uIHBlcmlvZCAoaXQgZW5kcyBvbiBPY3RvYmVyIDIsIDIwMTEpIGFuZCB3ZSBuZWVkIG1vcmUg bm9taW5lZXMgdGhhbiB3ZSBoYXZlIHJlY2VpdmVkIHNvIGZhci4gV2UgYXBwcmVjaWF0ZSB0aGUg Zm9sa3MgdGhhdCBoYXZlIHRha2VuIHRoZSB0aW1lIHRvIG5vbWluYXRlIHBlb3BsZSBhbmQgdGhv c2Ugd2hvIGhhdmUgYWNjZXB0ZWQgc28gZmFyLiBCdXQgdGhlIGZhY3QgcmVtYWlucyB0aGF0IHRo ZSBudW1iZXIgb2Ygbm9taW5hdGlvbnMgaGF2ZSBiZWVuIGJlbG93IGF2ZXJhZ2UgYW5kIHRoZSBh Y2NlcHRhbmNlIHJhdGVzIG9mIHRob3NlIG5vbWluYXRlZCBoYXMgYWxzbyBiZWVuIGxvdy4NCg0K V2UgbmVlZCAqKllPVVIqKiBpbnB1dCBhbmQgcGFydGljaXBhdGlvbiEgV2UgY2Fubm90IHByb3Bl cmx5IGV4ZWN1dGUgdGhlIHRhc2sgb2Ygc2VsZWN0aW5nIHRoZSBiZXN0IGNhbmRpZGF0ZXMgZm9y IHRoZXNlIHBvc2l0aW9ucyB3aXRoIHNvIGZldyBub21pbmF0aW9ucyBhbmQgYWNjZXB0YW5jZXMu IFNvLCBwbGVhc2UgY29uc2lkZXIgbWFraW5nIG5vbWluYXRpb25zIGZvciB0aGUgb3BlbiBwb3Np dGlvbnMsIGluIHBhcnRpY3VsYXIgdGhvc2UgZm9yIHdoaWNoIHdlIGhhdmUgc28gZmV3IG5vbWlu YXRpb25zICBpdCB0YWtlcyBqdXN0IGEgZmV3IG1pbnV0ZXMgb2YgeW91ciB0aW1lLiAgUmlnaHQg bm93LCB3ZSBqdXN0IG5lZWQgdGhlIG5hbWVzL2VtYWlsIGFkZHJlc3Nlcy4NCg0KV2h5IGRvIHdl IG5lZWQgbW9yZSBub21pbmF0aW9ucz8gIFdlbGwsIGV2ZW4gaWYgeW91IHRoaW5rIGEgd2lsbGlu ZyBpbmN1bWJlbnQgaXMgZG9pbmcgYSB2ZXJ5IGdvb2Qgam9iIGFuZCBzaG91bGQgYmUgcmV0dXJu ZWQsIGhpcyBvciBoZXIgYWJpbGl0eSB0byBzZXJ2ZSBhZ2FpbiBtaWdodCBiZSBpbXBhY3RlZCBi eSB1bmZvcmVzZWVuIGNpcmN1bXN0YW5jZXMgYmV0d2VlbiBub3cgYW5kIE1hcmNoLiBOb21Db20g bmVlZHMgdG8gY29uc2lkZXIgbXVsdGlwbGUgbm9taW5lZXMgdG8gYmUgcHJlcGFyZWQgaW4gdGhl IGV2ZW50IG9uZSBvciBtb3JlIGNhbmRpZGF0ZXMgaXMgdW5hYmxlIHRvIHNlcnZlIGNvbWUgbmV4 dCBNYXJjaCBhbmQgdG8gZW5zdXJlIHdlIGhhdmUgY2hvc2VuIHRoZSBiZXN0IGNhbmRpZGF0ZS4N Cg0KVGhlcmUgYXJlIHNldmVyYWwgd2F5cyB5b3UgY2FuIGhlbHAgdGhlIE5vbWNvbQ0KDQotIFlv dSBjYW4gbm9taW5hdGUgeW91cnNlbGYuDQotIFlvdSBjYW4gbm9taW5hdGUgc29tZW9uZSB5b3Ug a25vdyB3aG9tIHlvdSB0aGluayB3b3VsZCBkbyBhDQogIGdvb2Qgam9iLg0KDQpEb24ndCB3b3Jy eSBhYm91dCB3aGV0aGVyIHRoZXkgbWlnaHQgYWxyZWFkeSBiZSBub21pbmF0ZWQuIFdlIHdvdWxk IG11Y2ggcHJlZmVyIHRvIHJlY2VpdmUgdGhlIHNhbWUgbm9taW5hdGlvbiBzZXZlcmFsIHRpbWVz IHJhdGhlciB0aGFuIG1pc3MgYSBnb29kIHBlcnNvbiB3ZSBzaG91bGQgY29uc2lkZXIuDQoNCkhv dyB0byBzdWJtaXQgTm9taW5hdGlvbnM6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpU aGUgbGlzdCBvZiBwb3NpdGlvbnMgd2UgbmVlZCB0byBmaWxsLCBhbmQgdGhlIHByb3ZpZGVkIEpv YiBEZXNjcmlwdGlvbnMsIGFuZCBmb3JtcyBmb3Igbm9taW5hdGlvbnMsIGNhbiBiZSBmb3VuZCBp biB0aGUgY2FsbCBmb3Igbm9taW5hdGlvbnMgYXQ6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvYW5uL25vbWNvbS8zMDQ5Lw0KDQpZb3UgY2FuIGVudGVyIGEgbm9taW5hdGlvbiBieSBn b2luZyB0byB0aGUgZm9sbG93aW5nIFVSTDogDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2dyb3Vw L25vbWNvbS8yMDExL25vbWluYXRlDQoNCllvdSBjYW4gYWxzbyBub21pbmF0ZSBzb21lb25lIGJ5 IHNlbmRpbmcgYW4gZW1haWwgdG8gbm9tY29tMTFAaWV0Zi5vcmcgYW5kIGdpdmluZyB1cyB0aGVp ciBuYW1lLCBlbWFpbCBhZGRyZXNzIGFuZCB0aGUgb3BlbiBwb3NpdGlvbiB5b3UgYXJlIG5vbWlu YXRpbmcgdGhlbSBmb3IuIFdlIHdpbGwgdGFrZSBjYXJlIG9mIHRoZSByZXN0Lg0KDQpJZiB5b3Ug YXJlIGFza2VkIGZvciBhIHVzZXIgbmFtZSBhbmQgcGFzc3dvcmQsIHVzZSBhbiBleGlzdGluZyBp ZXRmIGxvZ2luIGFuZCBwYXNzd29yZC4gSWYgeW91IG5lZWQgYSBsb2dpbiBhbmQgcGFzc3dvcmQs IHJlcXVlc3Qgb25lIGZyb20gdGhlIGZvbGxvd2luZyBVUkw6DQoNCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvYWNjb3VudHMvY3JlYXRlLw0KDQoNCk9wZW4gTGlzdDoNCi0tLS0tLS0tLS0N Cg0KQXMgeW91IGFscmVhZHkga25vdywgTm9tQ29tIDIwMTEtMjAxMiB3aWxsIGZvbGxvdyB0aGUg cG9saWN5IGZvciAiT3BlbiBEaXNjbG9zdXJlIG9mIFdpbGxpbmcgTm9taW5lZXMiIGRlc2NyaWJl ZCBpbiBSRkMgNTY4MC4NCg0KRmVlZGJhY2sgQ29sbGVjdGlvbjoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNClRoZSBvcGVuIGxpc3QgaXMgY3VycmVudGx5IGF2YWlsYWJsZSBvbiB0aGUgTm9tY29t IHBhZ2UgYW5kIHRoZSBlbnRpcmUgY29tbXVuaXR5IGlzIGludml0ZWQgdG8gcHJvdmlkZSBmZWVk YmFjayBvbiBhbGwgbm9taW5lZXMuDQpZb3UgY2FuIHByb3ZpZGUgeW91ciBjb21tZW50cyBvbiBh bGwgd2lsbGluZyBub21pbmVlcyBhdCB0aGUgZm9sbG93aW5nIFVSTDoNCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvZ3JvdXAvbm9tY29tLzIwMTEvaW5wdXQvDQoNClN1cmVzaCBLcmlzaG5hbg0KQ2hh aXIsIE5vbUNvbSAyMDExLTIwMTINCm5vbWNvbS1jaGFpckBpZXRmLm9yZw0Kc3VyZXNoLmtyaXNo bmFuQGVyaWNzc29uLmNvbQ0K ------_=_NextPart_001_01CC75E4.72B1F984 Content-Type: text/plain; name="ATT6759294.txt" Content-Transfer-Encoding: base64 Content-Description: ATT6759294.txt Content-Disposition: attachment; filename="ATT6759294.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYtQW5u b3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCg== ------_=_NextPart_001_01CC75E4.72B1F984-- From internet-drafts@ietf.org Fri Sep 23 06:02:03 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFE621F8678; Fri, 23 Sep 2011 06:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km+o1tB3uipB; Fri, 23 Sep 2011 06:02:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BC821F85F7; Fri, 23 Sep 2011 06:02:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110923130202.20255.34653.idtracker@ietfa.amsl.com> Date: Fri, 23 Sep 2011 06:02:02 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 13:02:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : A YANG Data Model for Routing Configuration Author(s) : Ladislav Lhotka Filename : draft-ietf-netmod-routing-cfg-01.txt Pages : 51 Date : 2011-09-23 This document contains a specification of three YANG modules that together provide a data model for essential configuration of a routing subsystem. It is expected that this module will serve as a basis for further development of data models for individual routing protocols and other related functions. The present data model defines the common building blocks for such configurations - router instances, routes, routing tables, routing protocols and route filters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-routing-cfg-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-routing-cfg-01.txt