From owner-snmpconf@seymour39.SNMP.COM Fri Dec 1 06:42:36 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01408 for ; Fri, 1 Dec 2000 06:42:36 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id GAA04315 for snmpconf-outgoing; Fri, 1 Dec 2000 06:29:26 -0500 (EST) Message-Id: <200012011128.GAA23050@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpconf@snmp.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpconf-pm-04.txt Date: Fri, 01 Dec 2000 06:28:49 -0500 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Configuration Management with SNMP Working Group of the IETF. Title : Policy Based Management MIB Author(s) : S. Waldbusser, J. Saperia, T. Hongal Filename : draft-ietf-snmpconf-pm-04.txt Pages : 67 Date : 30-Nov-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, this MIB defines objects that enable policy-based configuration management of SNMP infrastructures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-pm-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpconf-pm-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpconf-pm-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130114125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-pm-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-pm-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130114125.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.SNMP.COM Sun Dec 3 01:37:25 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25794 for ; Sun, 3 Dec 2000 01:37:24 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id BAA17637 for snmpconf-outgoing; Sun, 3 Dec 2000 01:22:06 -0500 (EST) Message-ID: <15F58915DF84D311AC7D0090279AA6142341C4@itc-eml2.lannet.com> From: Dan Romascanu To: "'snmpconf@snmp.com'" Subject: snmpconf FW: November Milestones Date: Sun, 3 Dec 2000 08:21:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The SNMPCONF WG might be interesting in this message, from one of our Area Directors. This is part of a thread in the Traffic Engineering WG list. It does not relate to policy (maybe), but it certainly relates to Configuration by SNMP. Regards, Dan > -----Original Message----- > From: Randy Bush [SMTP:randy@psg.com] > Sent: Sun December 03 2000 7:13 > To: Kireeti Kompella > Cc: te-wg@UU.NET > Subject: Re: November Milestones > > i am not aware of significant operators using snmp to configure routers. > i know we don't allow snmp writes on any backbone or aggregation devices. > any large provider here (and not some vendor saying they know 10,000,000 > providers who are beating them up to do it) care to step forward and tell > us how they use snmp to configure? > > randy From owner-snmpconf@seymour39.SNMP.COM Sun Dec 3 01:43:33 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29037 for ; Sun, 3 Dec 2000 01:43:32 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id BAA17868 for snmpconf-outgoing; Sun, 3 Dec 2000 01:31:25 -0500 (EST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dan Romascanu Cc: "'snmpconf@snmp.com'" Subject: Re: snmpconf FW: November Milestones References: <15F58915DF84D311AC7D0090279AA6142341C4@itc-eml2.lannet.com> Message-Id: Date: Sat, 02 Dec 2000 22:30:51 -0800 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > The SNMPCONF WG might be interesting in this message, from one of our Area > Directors. actually, i was saying it as an operator, and in response to a question of whether a mib should be designed for config as well as read. my question of whether any large operators do puts was really meant at face value. i really want to know if any large providers enable and use write. randy From owner-snmpconf@seymour39.SNMP.COM Sun Dec 3 02:11:11 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17309 for ; Sun, 3 Dec 2000 02:11:10 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id BAA19128 for snmpconf-outgoing; Sun, 3 Dec 2000 01:59:42 -0500 (EST) Message-ID: <15F58915DF84D311AC7D0090279AA6142341C8@itc-eml2.lannet.com> From: Dan Romascanu To: "'Randy Bush'" Cc: "'snmpconf@snmp.com'" Subject: RE: snmpconf FW: November Milestones Date: Sun, 3 Dec 2000 08:58:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Randy, I think that I understood the intent of your question. This is a valid concern, and the SNMPCONF WG is supposed to try to deal with it in the BCP document. Though policy configuration is right now the focus of the SNMPCONF WG, the broader issue of any SNMP configuration in the larger networks space should be even a bigger concern. After all, if operators today do not trust SNMP for any kind of router configuration in large networks, why should they do it for policies? What should be done to change this situation? As and if answers will come back to the TE-WG list, the summary will certainly interest the SNMPCONF constituency. BTW, it would be useful to use a 'wearing my ... hat' type of disclaimer whenever you post such messages. It would help making the distinction between Randy_the_operator and Randy_the_Area_Director. Regards, Dan > -----Original Message----- > From: Randy Bush [SMTP:randy@psg.com] > Sent: Sun December 03 2000 8:31 > To: Dan Romascanu > Cc: 'snmpconf@snmp.com' > Subject: Re: snmpconf FW: November Milestones > > > The SNMPCONF WG might be interesting in this message, from one of our > Area > > Directors. > > actually, i was saying it as an operator, and in response to a question of > whether a mib should be designed for config as well as read. my question > of > whether any large operators do puts was really meant at face value. i > really want to know if any large providers enable and use write. > > randy From owner-snmpconf@seymour39.SNMP.COM Sun Dec 3 06:52:45 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21529 for ; Sun, 3 Dec 2000 06:52:45 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id GAA26696 for snmpconf-outgoing; Sun, 3 Dec 2000 06:41:03 -0500 (EST) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0A4AE5E8@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Dan Romascanu , snmpconf@snmp.com Subject: RE: snmpconf FW: November Milestones Date: Sun, 3 Dec 2000 12:40:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Comments inline > ---------- > From: Randy Bush[SMTP:randy@psg.com] > Reply To: snmpconf@snmp.com > Sent: Sunday, December 03, 2000 7:30 AM > To: Dan Romascanu > Cc: 'snmpconf@snmp.com' > Subject: Re: snmpconf FW: November Milestones > > > The SNMPCONF WG might be interesting in this message, from one of our > Area > > Directors. > > actually, i was saying it as an operator, and in response to a question of > whether a mib should be designed for config as well as read. my question > of > whether any large operators do puts was really meant at face value. i > really want to know if any large providers enable and use write. > I think MIBs should be designed for both monitoring AND configuration. If some vendors want to implemement just monitoring, then we can allow for that in a compliant way by specifying two sets of MODULE COMPLIANCE statements, one for read only and one for the full support including config. I also understand that up till now, a lot of operators have not used SNMP (v1 or v2c) because of security concerns. And in fact, some MIB designers have taken the read-only path as well, again because there was no security in SNMPv1/v2c. Therefore, I assume/hope that SNMPv3 will be exploited so that we can start to take a serious look to using SNMP for configuration management. So when we ask real operators as to if they do use SNMP to configure or not, then I think we should at the same time ask WHY they do or do not do that. What is the alternative? A bunch of inconsistent and non-interoperable CLI interfaces???? Bert > randy > From owner-snmpconf@seymour39.SNMP.COM Sun Dec 3 13:48:48 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23402 for ; Sun, 3 Dec 2000 13:48:48 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA27969 for snmpconf-outgoing; Sun, 3 Dec 2000 13:35:47 -0500 (EST) Message-ID: <3A2A9251.E8C87BF6@mediaone.net> Date: Sun, 03 Dec 2000 13:34:57 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com CC: Dan Romascanu Subject: Re: snmpconf FW: November Milestones References: <2413FED0DFE6D111B3F90008C7FA61FB0A4AE5E8@nl0006exch002u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Folks, an interesting string. Bert wrote: > So when we ask real operators as to if they do use SNMP to configure or > not, then I think we should at the same time ask WHY they do or do not > do that. > > What is the alternative? A bunch of inconsistent and non-interoperable > CLI interfaces???? > Regardless of the real and imagined reasons by all parties involved; few major network equipment vendors allow configuration with anything other than via flat files and CLI commands. If one accepts this point, asking if/who uses SNMP configuration in a backbone environment is at best rhetorical. Good and not so good reasons exist for this. The non or under specification of standards for configuration is a key factor. SNMPCONF should help since as a result of this WGs activity, people will better know how to write configuration objects at all levels of abstraction, a double win. Standard MIB Objects are only part of the issue. The lack of demand by customers for any configuration alternatives is another factor. Until now, the major issues for purchasing have been, cost per port/bit, HVAC, density, and other physical characteristics along with: does your BGP interoperate with Cisco, and does it scale? Even without the SNMPCONF work, some of the newer players, especially those providing edge technology have fuller instrumentation (including SNMP Config). The reason is; CLI's and file transfer will not continue to scale at least at a human level. The economics of the availability of personnel who can manage networks that are controlled with CLI's will be the factor that causes operators to ask for something better. That has not happened until recently. One can debate (and we sure have:-)) a variety of alternatives for improving configuration technology. I think arguments for maintenance of the status quo would be hard to make convincingly. When 'collecting' input about what operators want, other than coexistence with what they have, what I try to find out are things like: How fast do they need to cause a configuration change, how much computing resource are they willing to pay for to make the change, how willing are they to ask the vendors for this, and what types of operational problems (other than scare human resources) do they have such as fault isolation time, coordinated configuration changes, etc? I think SNMPCONF will help in many of these areas. Configuration is the heart of management. To the extent MIB Documents are created in each of the different technology areas such as routing or differentiated services (which is the right place), they should be designed for full coverage including configuration. There is no excuse not to. /jon From owner-snmpconf@seymour39.SNMP.COM Sun Dec 3 14:35:58 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08662 for ; Sun, 3 Dec 2000 14:35:58 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA28178 for snmpconf-outgoing; Sun, 3 Dec 2000 14:25:02 -0500 (EST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jon Saperia Cc: snmpconf@snmp.com Subject: Re: snmpconf FW: November Milestones References: <2413FED0DFE6D111B3F90008C7FA61FB0A4AE5E8@nl0006exch002u.nl.lucent.com> <3A2A9251.E8C87BF6@mediaone.net> Message-Id: Date: Sun, 03 Dec 2000 11:24:27 -0800 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit [ operator hat only ] > few major network equipment vendors allow configuration with anything > other than via flat files and CLI commands. in the backbone router market, there are two vendors. both claim that their equipment can be configured using snmp write. i just don't know anyone who has tried it. > The reason is; CLI's and file transfer will not continue to scale at least > at a human level. The economics of the availability of personnel who can > manage networks that are controlled with CLI's will be the factor that > causes operators to ask for something better. That has not happened until > recently. to keep apples and apples, how many people can type snmp stuff directly to a router? darned few. and who cares? like mibs, the text config files are merely an intermediate representation. do not underestimate the value of being able to email snippets of configs, cvs them, diff them, ... there is a vast array of tools which work on text. think about having to write a tool to determine the difference between a running config and a proposed new config and emailing an easily understood representation of the poposed change to a distributed team. > Configuration is the heart of management. To the extent MIB Documents > are created in each of the different technology areas such as routing or > differentiated services (which is the right place), they should be > designed for full coverage including configuration. There is no excuse > not to. i do not intend to discourage those who wish to design for write from doing so. but i am not sure i see a need to mandate it when doing so would cause complexity or architectural change. and i believe that, and only that, was the question (in the tewg) that [re]started this rathole. randy From owner-snmpconf@seymour39.SNMP.COM Sun Dec 3 15:56:36 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02797 for ; Sun, 3 Dec 2000 15:56:35 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA28483 for snmpconf-outgoing; Sun, 3 Dec 2000 15:43:13 -0500 (EST) Message-ID: <3A2AB02C.C8308488@mediaone.net> Date: Sun, 03 Dec 2000 15:42:20 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: snmpconf@snmp.com Subject: Re: snmpconf FW: November Milestones References: <2413FED0DFE6D111B3F90008C7FA61FB0A4AE5E8@nl0006exch002u.nl.lucent.com> <3A2A9251.E8C87BF6@mediaone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Randy Bush wrote: > > [ operator hat only ] > > > few major network equipment vendors allow configuration with anything > > other than via flat files and CLI commands. > > in the backbone router market, there are two vendors. both claim that their > equipment can be configured using snmp write. i just don't know anyone who > has tried it. Assuming you mean Juniper and Cisco. It is true that Cisco has an object that you can set that causes it to ask for a file download (Juniper may also - I just do not know). There are a few (very few) setable parameters that can be set from either vendor. To claim either of these is configurable via SNMP falls outside the limits of credibility. > > > The reason is; CLI's and file transfer will not continue to scale at least > > at a human level. The economics of the availability of personnel who can > > manage networks that are controlled with CLI's will be the factor that > > causes operators to ask for something better. That has not happened until > > recently. > > to keep apples and apples, how many people can type snmp stuff directly to a > router? darned few. and who cares? So your point is? SNMP is not intended as a user interface. It is a method of defining management objects, a protocol for their transmission, and an administrative framework. Few people can read LSAs on the wire either. > > like mibs, the text config files are merely an intermediate representation. > do not underestimate the value of being able to email snippets of configs, > cvs them, diff them, ... there is a vast array of tools which work on text. > think about having to write a tool to determine the difference between a > running config and a proposed new config and emailing an easily understood > representation of the poposed change to a distributed team. True, that does not mean that intermediate forms have to be the method of transport (or storage) for the configuration information. Databases and other systems have done at least as good a job as most text tools do in determining differences. It is probably easier, and in the long run less costly since each ISP would not have to reinvent the wheel for all the text manipulation tools again and modify them all over again each time a vendor changed file formats or added new parameters. What is also true is that operational staff people have an investment in what they know which should not be undervalued. It is also true that investment makes them less amenable to change which is not in the financial best interests of the company if one believes that there really is a scarcity of human resources. More people and hand crafted tools that can parse a number of different configuration file formats does not seem like the best solution. > > > Configuration is the heart of management. To the extent MIB Documents > > are created in each of the different technology areas such as routing or > > differentiated services (which is the right place), they should be > > designed for full coverage including configuration. There is no excuse > > not to. > > i do not intend to discourage those who wish to design for write from doing > so. but i am not sure i see a need to mandate it when doing so would cause > complexity or architectural change. and i believe that, and only that, was > the question (in the tewg) that [re]started this rathole. That is why we have the problem in configuration today where everyone does it themselves. Put a Cisco and Juniper config file next to each other and try to parse their meaning if you do not know each of them intimately. It is harder to write configure configuration code (using any method) than reading counters. There is a need for a standard that can expand to accommodate vendor differences. I see this as the justification for the extra work. /jon From owner-snmpconf@seymour39.SNMP.COM Sun Dec 3 20:14:09 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18408 for ; Sun, 3 Dec 2000 20:14:08 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id UAA29804 for snmpconf-outgoing; Sun, 3 Dec 2000 20:01:54 -0500 (EST) Message-Id: <5.0.2.1.1.20001203160442.00a99660@mordor> X-Sender: mrm@mordor X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 03 Feb 2001 17:08:16 -0800 To: snmpconf@snmp.com From: Mike MacFaden Subject: Routers and SNMP (was Re: snmpconf FW: November Milestones) In-Reply-To: <15F58915DF84D311AC7D0090279AA6142341C4@itc-eml2.lannet.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Bush, Randy might have said this: >> i am not aware of significant operators using snmp to configure routers I agree. For transit networks, this is absolutely true today. Yet in the future, maybe it will be less true especially in areas where there is a need for constant change to a configuration and using a CLI/expect script does not offer the precision and speed needed over x generations of a given vendors CLI. Most configurations are pretty much set-and-forget on routers for the most part anyway today, but again that may change with all the new traffic engineering/constraint based routing work, RSVP-TE stuff. I see two major reasons why this state of affairs is so and why it remains that way for Routing. Reason 1) It has been my experience that an SNMP interface is more costly, requires skills genererally not found in the vendors engineering groups due to cross-disipline needs for both Net Mgmt AND Routing. Routing code is hard enough thus any longer effort needed to deliver a working agent than the average vendor's CLI means longer time to market. ....Sure would be very curious as to what would Greg Satz might say today... So operators pay the cost in terms of operational pain but so far don't complain too loudly about it if at all. Yet I bet anyone a nickle that operators running rtConfig would prefer if a simpler tool that didn't have to keep up with vendor CLI versions: cisco, bay, gated, rsd...so long as it remained easy to debug. The cost of implementing read-write SNMP objects must be justified... and it truely can be but the payback is not usually immediate. Lastly, there is no artifical barrier to entry into the router market that says you have to have SNMP configuration like there is with MSOs running HFC networks which will make up the single largest group of network operators using SNMP configuration today. Translation: DOCSIS Cable Modems and CMTSs. And these folks really do need SNMP technology since their operations staff, as CTO of a very large Tier 1 service provider to the MSO customer set recently told me, tend to be on the less skilled side... The Internet Standard Management Framework provides a precice, consistent managment interface across vendor devices since DOCSIS mandates what MIB modules one must support and the level of support is clear. Reason 2) Routing configurations, if done wrong, have global impact on the Internet. Randy's oft posts to NANOG mailing list about AS's advertising prefixes they don't own, etc is evidence. Unlike most of the systems SNMP configures today, configuring Routing in the Internet is not something that has not been completely automated and requires constant vigil by highly trained personnel. I have hope that one day the routing working groups will get it right and figure out how to design into the protocols ways/defaults of dealing with bad input to configuration such that it will not cause outages on a more global scope. Then eventually configuration of routers will become an ordinary procedure and be capable of automation (CLI/SNMP) without worry that you can blank hole many prefixes the next through three service providers you peer with. Sure CLI's can be scripted, but everyone I know of would prefer a more precise interface so long as it adheres to most of that is in the SNMPCONF BCP.... :-) Regards, Mike MacFaden www.riverstonenet.com From owner-snmpconf@seymour39.SNMP.COM Mon Dec 4 00:25:07 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06492 for ; Mon, 4 Dec 2000 00:25:07 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id AAA02889 for snmpconf-outgoing; Mon, 4 Dec 2000 00:13:01 -0500 (EST) Date: Sun, 03 Dec 2000 21:07:31 -0800 From: Andrew Smith Subject: Re: snmpconf FW: November Milestones To: snmpconf@snmp.com, diffserv Cc: Jon Saperia , Randy Bush Message-id: <3A2B2693.7000800@allegronetworks.com> Organization: Allegro Networks MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en References: <2413FED0DFE6D111B3F90008C7FA61FB0A4AE5E8@nl0006exch002u.nl.lucent.com> <3A2A9251.E8C87BF6@mediaone.net> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit From a thread from the snmpconf WG: > Jon wrote: >> Configuration is the heart of management. To the extent MIB Documents >> are created in each of the different technology areas such as routing or >> differentiated services (which is the right place), they should be >> designed for full coverage including configuration. There is no excuse >> not to. > Randy wrote: > i do not intend to discourage those who wish to design for write from doing > so. but i am not sure i see a need to mandate it when doing so would cause > complexity or architectural change. and i believe that, and only that, was > the question (in the tewg) that [re]started this rathole. > > randy Randy's point is well made - I don't think it is a rathole - and is directly relevant to the MIB/PIB/snmpconf/DSMON discussions for diffserv management. In the various iterations of the diffserv MIB we have veered between extremes of optimise-for-read and optimise-for-configure without, I think, a clear idea of why. The -04 version tended towards the former whilst the latest incarnation (-06) veers back towards the latter in the interests of consistency with the PIB work and the "template" concept for the diffserv policy MIB (snmpconf WG). Should we treat these as valid reasons to sacrifice read performance or should we find another way to optimise opbjects for configuration e.g. by duplication (indexing of same information in multiple ways)? Right now, I believe the -06 MIB does cause additional complexity for reading. Andrew From owner-snmpconf@seymour39.SNMP.COM Mon Dec 4 00:28:12 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07148 for ; Mon, 4 Dec 2000 00:28:12 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id AAA03865 for snmpconf-outgoing; Mon, 4 Dec 2000 00:16:54 -0500 (EST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mike MacFaden Cc: snmpconf@snmp.com Subject: Re: Routers and SNMP (was Re: snmpconf FW: November Milestones) References: <15F58915DF84D311AC7D0090279AA6142341C4@itc-eml2.lannet.com > <5.0.2.1.1.20001203160442.00a99660@mordor> Message-Id: Date: Sun, 03 Dec 2000 21:15:04 -0800 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > Sure CLI's can be scripted, but everyone I know of would prefer a more > precise interface so long as it adheres to most of that is in the SNMPCONF > BCP.... :-) you may have noted that i was very careful not to speak for others. randy From owner-snmpconf@seymour39.SNMP.COM Mon Dec 4 00:32:06 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07981 for ; Mon, 4 Dec 2000 00:32:05 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id AAA04304 for snmpconf-outgoing; Mon, 4 Dec 2000 00:21:44 -0500 (EST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Andrew Smith Cc: snmpconf@snmp.com, diffserv Subject: Re: snmpconf FW: November Milestones References: <2413FED0DFE6D111B3F90008C7FA61FB0A4AE5E8@nl0006exch002u.nl.lucent.com> <3A2A9251.E8C87BF6@mediaone.net> <3A2B2693.7000800@allegronetworks.com> Message-Id: Date: Sun, 03 Dec 2000 21:21:06 -0800 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit [ operator hat only ] we do a LOT of reads, so many that we have to gang boxes to do them, and write tools to manage the poller array. if we were to do snmp config, i presume it would be FAR fewer operations than the polls and other gets. randy From owner-snmpconf@seymour39.SNMP.COM Mon Dec 4 09:00:29 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24949 for ; Mon, 4 Dec 2000 09:00:29 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA18881 for snmpconf-outgoing; Mon, 4 Dec 2000 08:47:12 -0500 (EST) Message-ID: <3A2BA02D.1FA4582B@mediaone.net> Date: Mon, 04 Dec 2000 08:46:21 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com CC: diffserv , Randy Bush Subject: Re: snmpconf FW: November Milestones References: <2413FED0DFE6D111B3F90008C7FA61FB0A4AE5E8@nl0006exch002u.nl.lucent.com> <3A2A9251.E8C87BF6@mediaone.net> <3A2B2693.7000800@allegronetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > Randy's point is well made - I don't think it is a rathole - and is directly > relevant to the MIB/PIB/snmpconf/DSMON discussions for diffserv management. In > the various iterations of the diffserv MIB we have veered between extremes of > optimise-for-read and optimise-for-configure without, I think, a clear idea of > why. The -04 version tended towards the former whilst the latest incarnation > (-06) veers back towards the latter in the interests of consistency with the PIB > work and the "template" concept for the diffserv policy MIB (snmpconf WG). > Should we treat these as valid reasons to sacrifice read performance or should > we find another way to optimise opbjects for configuration e.g. by duplication > (indexing of same information in multiple ways)? Right now, I believe the -06 > MIB does cause additional complexity for reading. > > Andrew > It is often the case that read only MIB documents are not well designed in a number of respects. Relevant to this discussion is that the indices are often created with implementation ease in mind. It is more difficult to implement a table with multiple indices (regardless of basic technology) than to use simple integer index values. This is true whether the objects are read only or read write. This poor design, while easy for software engineers, causes unnecessary data collection overhead since it is more difficult to 'scope' what you want to retrieve (Randy indirectly alluded to this in a previous post). In some cases, the design makes it quite difficult not mater how much data you collect to understand what it means in terms of the configuration. My view is that the additional complexity for configuration will pay off in terms of better quality data and less data movement. This is not to say -06 is just right, there are other who can better assess that. My point is that it is worth the work. /jon From owner-snmpconf@seymour39.SNMP.COM Sun Dec 10 02:38:26 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28595 for ; Sun, 10 Dec 2000 02:38:25 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id CAA17662 for snmpconf-outgoing; Sun, 10 Dec 2000 02:19:09 -0500 (EST) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0A670510@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Andrea Westerinen , snmpconf@snmp.com Cc: Policy Mailing List Subject: RE: snmpconf Re: Comments on the draft-ietf-policy-terminology-00 .txt document Date: Sun, 10 Dec 2000 08:18:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com > ---------- > From: Jon Saperia[SMTP:saperia@mediaone.net] > Reply To: snmpconf@snmp.com > Sent: Tuesday, November 21, 2000 11:01 AM > To: Andrea Westerinen > Cc: policy@raleigh.ibm.com; snmpconf > Subject: snmpconf Re: Comments on the > draft-ietf-policy-terminology-00.txt document > > Thanks for all the comments. I look forward to the next draft. > > /jon > From owner-snmpconf@seymour39.SNMP.COM Mon Dec 11 00:01:55 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25731 for ; Mon, 11 Dec 2000 00:01:55 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id XAA22940 for snmpconf-outgoing; Sun, 10 Dec 2000 23:48:29 -0500 (EST) From: "Andrea Westerinen" To: Cc: "diffserv" , "Randy Bush" Subject: RE: snmpconf FW: November Milestones Date: Sun, 10 Dec 2000 20:52:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3A2BA02D.1FA4582B@mediaone.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Some of the info modeling work may be pertinent here. Some of the models separate state and current operational data from configuration information. The latter is described by Setting classes and collected into Configuration aggregations. You can send clearly defined Setting classes and instances to a device. You can "apply" these Settings to a device and/or its components. You can retrieve (read mostly) current state/operational data from other classes and instances. Just FYI... Andrea -----Original Message----- From: owner-snmpconf@snmp.com [mailto:owner-snmpconf@snmp.com]On Behalf Of Jon Saperia Sent: Monday, December 04, 2000 5:46 AM To: snmpconf@snmp.com Cc: diffserv; Randy Bush Subject: Re: snmpconf FW: November Milestones > Randy's point is well made - I don't think it is a rathole - and is directly > relevant to the MIB/PIB/snmpconf/DSMON discussions for diffserv management. In > the various iterations of the diffserv MIB we have veered between extremes of > optimise-for-read and optimise-for-configure without, I think, a clear idea of > why. The -04 version tended towards the former whilst the latest incarnation > (-06) veers back towards the latter in the interests of consistency with the PIB > work and the "template" concept for the diffserv policy MIB (snmpconf WG). > Should we treat these as valid reasons to sacrifice read performance or should > we find another way to optimise opbjects for configuration e.g. by duplication > (indexing of same information in multiple ways)? Right now, I believe the -06 > MIB does cause additional complexity for reading. > > Andrew > It is often the case that read only MIB documents are not well designed in a number of respects. Relevant to this discussion is that the indices are often created with implementation ease in mind. It is more difficult to implement a table with multiple indices (regardless of basic technology) than to use simple integer index values. This is true whether the objects are read only or read write. This poor design, while easy for software engineers, causes unnecessary data collection overhead since it is more difficult to 'scope' what you want to retrieve (Randy indirectly alluded to this in a previous post). In some cases, the design makes it quite difficult not mater how much data you collect to understand what it means in terms of the configuration. My view is that the additional complexity for configuration will pay off in terms of better quality data and less data movement. This is not to say -06 is just right, there are other who can better assess that. My point is that it is worth the work. /jon From owner-snmpconf@seymour39.SNMP.COM Wed Dec 13 12:50:29 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19644 for ; Wed, 13 Dec 2000 12:50:28 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA16193 for snmpconf-outgoing; Wed, 13 Dec 2000 12:28:48 -0500 (EST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joseph Dube Cc: Rob Frye , TE Working Group , SNMPv3 Working Group , SNMPconf Working Group Subject: snmpconf Re: TE-MIB readonly or read/write References: <3A36D5D5.B12D252F@longsys.com> <3A37A982.805318E2@mailhost.avici.com> Message-Id: Date: Wed, 13 Dec 2000 09:28:17 -0800 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > Please note that there is another mib containing a superset of the contents > of draft-ietf-tewg-mib-00.txt (Kireeti's mib). This other mib is called > draft-ietf-mpls-te-mib-05.txt and it allows management and configuration via > SNMP. it may help to think of kompella's at the api between ccamp and tewg/ppvpn, and nadeu's as at the border between ccamp and mpls. randy From owner-snmpconf@seymour39.SNMP.COM Wed Dec 13 13:12:48 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23968 for ; Wed, 13 Dec 2000 13:12:48 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA16693 for snmpconf-outgoing; Wed, 13 Dec 2000 12:59:21 -0500 (EST) Message-Id: <200012131759.MAA16686@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 to: snmpconf@snmp.com Subject: snmpconf TE-MIB readonly or read/write Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 13 Dec 2000 12:59:19 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit The following message is being forwarded to snmpconf after being bounced due to an address change. ------- Forwarded Message Received: by seymour39.SNMP.COM (8.9.3/m.000221) id LAA15362; Wed, 13 Dec 2000 11:31:06 -0500 (EST) Date: Wed, 13 Dec 2000 11:31:06 -0500 (EST) From: owner-snmpconf@snmp.com Message-Id: <200012131631.LAA15362@seymour39.SNMP.COM> To: owner-snmpconf@snmp.com Subject: BOUNCE snmpconf@majordomo.snmp.com: Non-member submission from [Rob Frye ] >From owner-snmpconf@seymour39.SNMP.COM Wed Dec 13 11:31:03 2000 Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by seymour39.SNMP.COM (8.9.3/m.000221) with ESMTP id LAA15345 for ; Wed, 13 Dec 2000 11:31:03 -0500 (EST) Received: from longsys.com (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id eBDGUdN06166; Wed, 13 Dec 2000 16:30:39 GMT Message-ID: <3A36D5D5.B12D252F@longsys.com> Date: Tue, 12 Dec 2000 17:50:14 -0800 From: Rob Frye Organization: Longitude Systems, Inc. X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: TE Working Group CC: SNMPv3 Working Group , SNMPconf Working Group Subject: TE-MIB readonly or read/write Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In today's TEWG session, Kireeti stated that SNMP is used only for monitoring and shouldn't (according to various ISP's) be used for management/configuration. I recommend that the TE MIB be usable for configuration for those things that can't be configured via LSP setup [whether by RSVP or LDP/CR-LDP]. SNMPv3 is gaining ground in some areas, and it's a positive cause-and-effect spiral: the more ISPs & IT depts are able to use SNMPv3 for device management, the more they want to be able to do so uniformly, and thus drive the availability & support for SNMPv3 elsewhere. I would like the MIB to be read/write. -- // Rob. Rob Frye Director, Software Development Longitude Systems, Inc. 15000 Conference Center Drive Chantilly, VA 20151 www.longsys.com voice: +1-703-818-5426 fax: +1-703-961-8751 mobile: +1-703-725-1130 email: rfrye@longsys.com ------- End of Forwarded Message From owner-snmpconf@seymour39.SNMP.COM Wed Dec 13 13:14:25 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24152 for ; Wed, 13 Dec 2000 13:14:25 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA16724 for snmpconf-outgoing; Wed, 13 Dec 2000 13:00:32 -0500 (EST) Message-Id: <200012131800.NAA16717@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 to: snmpconf@snmp.com Subject: snmpconf Re: TE-MIB readonly or read/write Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 13 Dec 2000 13:00:30 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Forwarding bounced message. ------- Forwarded Message Message-ID: <3A37A982.805318E2@mailhost.avici.com> Date: Wed, 13 Dec 2000 11:53:22 -0500 From: Joseph Dube X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Frye CC: TE Working Group , SNMPv3 Working Group , SNMPconf Working Group Subject: Re: TE-MIB readonly or read/write References: <3A36D5D5.B12D252F@longsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rob, Please note that there is another mib containing a superset of the contents of draft-ietf-tewg-mib-00.txt (Kireeti's mib). This other mib is called draft-ietf-mpls-te-mib-05.txt and it allows management and configuration via SNMP. -Joe Rob Frye wrote: > In today's TEWG session, Kireeti stated that SNMP is used only for > monitoring and shouldn't (according to various ISP's) be used for > management/configuration. I recommend that the TE MIB be usable for > configuration for those things that can't be configured via LSP setup > [whether by RSVP or LDP/CR-LDP]. SNMPv3 is gaining ground in some > areas, and it's a positive cause-and-effect spiral: the more ISPs & IT > depts are able to use SNMPv3 for device management, the more they want > to be able to do so uniformly, and thus drive the availability & support > for SNMPv3 elsewhere. > > I would like the MIB to be read/write. > > -- > // Rob. > > Rob Frye > Director, Software Development > Longitude Systems, Inc. > 15000 Conference Center Drive > Chantilly, VA 20151 > www.longsys.com > voice: +1-703-818-5426 > fax: +1-703-961-8751 > mobile: +1-703-725-1130 > email: rfrye@longsys.com ------- End of Forwarded Message From owner-snmpconf@seymour39.SNMP.COM Wed Dec 13 13:17:07 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24458 for ; Wed, 13 Dec 2000 13:17:06 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA16780 for snmpconf-outgoing; Wed, 13 Dec 2000 13:02:52 -0500 (EST) Message-Id: <200012131802.NAA16773@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 to: snmpconf@snmp.com Subject: snmpconf Re: TE-MIB readonly or read/write Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 13 Dec 2000 13:02:50 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Forwarded bounced message ------- Forwarded Message Date: Wed, 13 Dec 2000 12:36:11 -0500 (EST) From: Tony Tauber X-Sender: To: Rob Frye cc: TE Working Group , SNMPv3 Working Group , SNMPconf Working Group Subject: Re: TE-MIB readonly or read/write In-Reply-To: <3A36D5D5.B12D252F@longsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I would like the MIB to be read/write. I'm inclined to agree. I don't do SNMP sets and believe that's the common practice among operators today (as Randy mentioned), but can't see a good architectural reason to deny this possiblity right out of the gate and box ourselves in. If people choose not to use this capability or to administratively prohibit it, that's fine; just like is done with SNMP sets today. Tony ------- End of Forwarded Message From owner-snmpconf@seymour39.SNMP.COM Wed Dec 13 13:19:27 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24720 for ; Wed, 13 Dec 2000 13:19:27 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA16894 for snmpconf-outgoing; Wed, 13 Dec 2000 13:06:38 -0500 (EST) Message-Id: <200012131806.NAA16887@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 to: snmpconf@snmp.com Subject: snmpconf Re: TE-MIB readonly or read/write Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 13 Dec 2000 13:06:36 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Forwarding bounced email msssage. ------- Forwarded Message Date: Wed, 13 Dec 2000 09:50:31 -0800 From: Rob Frye Organization: Longitude Systems, Inc. X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Joseph Dube , TE Working Group , SNMPv3 Working Group , SNMPconf Working Group Subject: Re: TE-MIB readonly or read/write References: <3A36D5D5.B12D252F@longsys.com> <3A37A982.805318E2@mailhost.avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy Bush wrote: > > Please note that there is another mib containing a superset of the contents > > of draft-ietf-tewg-mib-00.txt (Kireeti's mib). This other mib is called > > draft-ietf-mpls-te-mib-05.txt and it allows management and configuration via > > SNMP. > > it may help to think of kompella's at the api between ccamp and tewg/ppvpn, > and nadeu's as at the border between ccamp and mpls. Thanks Joe & Randy for the pointers to Nadeu's draft & how to view the two. I'll compare the two with that thought in mind. However, I think Tony Tauber said what I was trying to get at: Tony> [I] can't see a good architectural reason to deny this possiblity right Tony> out of the gate and box ourselves in. Tony> If people choose not to use this capability or to administratively Tony> prohibit it, that's fine ... -- // Rob. Rob Frye Director, Software Development Longitude Systems, Inc. 15000 Conference Center Drive Chantilly, VA 20151 www.longsys.com voice: +1-703-818-5426 fax: +1-703-961-8751 mobile: +1-703-725-1130 email: rfrye@longsys.com ------- End of Forwarded Message From owner-snmpconf@seymour39.SNMP.COM Wed Dec 13 13:19:40 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24758 for ; Wed, 13 Dec 2000 13:19:39 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA16839 for snmpconf-outgoing; Wed, 13 Dec 2000 13:05:18 -0500 (EST) Message-Id: <200012131805.NAA16832@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 to: snmpconf@snmp.com Subject: snmpconf Re: TE-MIB readonly or read/write Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 13 Dec 2000 13:05:16 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit I am forwarding the following bounced email message. ------- Forwarded Message From: Spencer.Giacalone@predictive.com To: Joseph Dube Cc: owner-te-wg@UU.NET, Rob Frye , SNMPconf Working Group , SNMPv3 Working Group , TE Working Group Subject: Re: TE-MIB readonly or read/write X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 13 Dec 2000 12:50:25 -0500 X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.0.5 |September 22, 2000) at 12/13/2000 12:51:36 PM, Serialize complete at 12/13/2000 12:51:36 PM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I also think the MIB should be read-write. On a slightly separate note, I think it makes sense to keep TE items out of the IGP MIBs (as per Kireeti's question). -Spence Joseph Dube Sent by: owner-te-wg@UU.NET 12/13/00 11:53 AM To: Rob Frye cc: TE Working Group , SNMPv3 Working Group , SNMPconf Working Group Subject: Re: TE-MIB readonly or read/write Rob, Please note that there is another mib containing a superset of the contents of draft-ietf-tewg-mib-00.txt (Kireeti's mib). This other mib is called draft-ietf-mpls-te-mib-05.txt and it allows management and configuration via SNMP. -Joe Rob Frye wrote: > In today's TEWG session, Kireeti stated that SNMP is used only for > monitoring and shouldn't (according to various ISP's) be used for > management/configuration. I recommend that the TE MIB be usable for > configuration for those things that can't be configured via LSP setup > [whether by RSVP or LDP/CR-LDP]. SNMPv3 is gaining ground in some > areas, and it's a positive cause-and-effect spiral: the more ISPs & IT > depts are able to use SNMPv3 for device management, the more they want > to be able to do so uniformly, and thus drive the availability & support > for SNMPv3 elsewhere. > > I would like the MIB to be read/write. > > -- > // Rob. > > Rob Frye > Director, Software Development > Longitude Systems, Inc. > 15000 Conference Center Drive > Chantilly, VA 20151 > www.longsys.com > voice: +1-703-818-5426 > fax: +1-703-961-8751 > mobile: +1-703-725-1130 > email: rfrye@longsys.com ------- End of Forwarded Message From owner-snmpconf@seymour39.SNMP.COM Wed Dec 13 14:27:57 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07894 for ; Wed, 13 Dec 2000 14:27:54 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id OAA17776 for snmpconf-outgoing; Wed, 13 Dec 2000 14:14:03 -0500 (EST) Message-ID: <3A37CB48.E06A492A@longsys.com> Date: Wed, 13 Dec 2000 11:17:28 -0800 From: Rob Frye Organization: Longitude Systems, Inc. X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Ben Black CC: SNMPv3 Working Group , SNMPconf Working Group Subject: snmpconf Re: TE-MIB readonly or read/write References: <3A36D5D5.B12D252F@longsys.com> <20001213101833.D2220@layer8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit NOTE: I have dropped "TE" from this message, as it is not pertinent/specific to TE. Ben Black wrote: > could you give examples of large ISPs who are asking for additional > SNMP configuration features? i am not at all a fan of using SNMP for > router configuration, and i believe that puts me in the majority among > service provider engineers. > > ben CAVEAT to my answer here: I do not speak for the ISPs I mention below; I only speak from the basis of prior conversations & IETF meetings. I don't think there are ISPs who have asked for "additional SNMP configuration features", as I understand the phrase, so much as asking for more devices to be able to be fully-configurable using SNMP with appropriate security. On the latter, I know that UUnet was, at one time, strongly pushing for SNMPv3 implementation by NMS & device vendors so they could deploy it in their network & get away from command-line interface configuration of routers. Other ISPs, including at least Verio, have supported that in the past. There have been discussions about additional (SNMP) management capabilities in various fora, discussions, etc. such as aggregate objects (including but not limited to full table rows & full tables), other security models, and more. -- // Rob. Rob Frye Director, Software Development Longitude Systems, Inc. 15000 Conference Center Drive Chantilly, VA 20151 www.longsys.com voice: +1-703-818-5426 fax: +1-703-961-8751 mobile: +1-703-725-1130 email: rfrye@longsys.com From owner-snmpconf@seymour39.SNMP.COM Sat Dec 16 17:19:12 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00805 for ; Sat, 16 Dec 2000 17:19:12 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA15234 for snmpconf-outgoing; Sat, 16 Dec 2000 17:03:05 -0500 (EST) Message-ID: <3A3BE661.E72F9093@mediaone.net> Date: Sat, 16 Dec 2000 17:02:09 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bert Wijnen , Randy Bush , SNMP Configuration WG , David Partain , Jon Saperia Subject: snmpconf SNMPCONF WG Summary - 49th IETF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit The SNMPCONF WG met twice during the 49th IETF and made progress on a number of issues. A review of recent changes to the Policy MIB Module were discussed with agreement that some will be carried to the working group mailing list. A review of the difficulty in using the Schedule MIB Module was followed by a proposal for a customized version to be included with the Policy Module. The Best Current Practices document was reviewed with the request that suggestions for additional material be sent to the mailing list. Presentations and discussions followed on accessor functions language and policy grouping and precedence issues. Presentations of the DiffServ Policy and DiffServ MIB Modules and their interrelationships along with new TCs were made. The WG concluded with a brief discussion about the need for an interim meeting. This will be taken to the mail list after a list of 'to do' items has been published. If we are to have a meeting we need to decide before the end of this calendar year. /jon From owner-snmpconf@seymour39.SNMP.COM Mon Dec 18 04:06:12 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06775 for ; Mon, 18 Dec 2000 04:06:11 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id DAA14317 for snmpconf-outgoing; Mon, 18 Dec 2000 03:50:15 -0500 (EST) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0A7AB71D@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'David Partain'" , Jon Saperia , snmpconf@snmp.com Cc: Randy Bush Subject: RE: snmpconf SNMPCONF WG Summary - 49th IETF Date: Mon, 18 Dec 2000 09:49:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Thanks fo rthe summary Bert From owner-snmpconf@seymour39.SNMP.COM Mon Dec 18 06:49:22 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07657 for ; Mon, 18 Dec 2000 06:49:22 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id GAA14833 for snmpconf-outgoing; Mon, 18 Dec 2000 06:33:08 -0500 (EST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 18 Dec 2000 06:34:36 -0500 Subject: snmpconf Re: TE-MIB readonly or read/write From: Jon Saperia To: Tony Tauber , Rob Frye , Jon Saperia CC: TE Working Group , SNMPv3 Working Group , SNMPconf Working Group Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 12/13/2000 12:36 PM, Tony Tauber at ttauber@genuity.net wrote: > I'm inclined to agree. > > I don't do SNMP sets and believe that's the common practice > among operators today (as Randy mentioned), but can't see > a good architectural reason to deny this possiblity right > out of the gate and box ourselves in. > > If people choose not to use this capability or to administratively > prohibit it, that's fine; just like is done with SNMP sets today. There has been quite a lot of email on this topic. The two paragraphs above make two good points. One of the reasons operators do not do much with SNMP sets today is that there are very very few standard objects to set. I believe the job of the people developing the standard MIB Modules is to provide complete management coverage. For those operators that do not wish to use set operations, they can continue not to use them. This time they will have a real choice, not because there is not much worthwhile to do with them as has historically been the case. The issue that I have raised is that for the newly created area, we should provide complete coverage. /jon From owner-snmpconf@seymour39.SNMP.COM Mon Dec 18 14:28:34 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13809 for ; Mon, 18 Dec 2000 14:28:33 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id OAA26747 for snmpconf-outgoing; Mon, 18 Dec 2000 14:04:10 -0500 (EST) Message-ID: <002701c06925$f6e541a0$b2aea8c0@erilab.com> From: "Suresh Krishnan" To: , "Tony Tauber" , "Rob Frye" , "Jon Saperia" Cc: "TE Working Group" , "SNMPv3 Working Group" , "SNMPconf Working Group" References: Subject: Re: snmpconf Re: TE-MIB readonly or read/write Date: Mon, 18 Dec 2000 11:08:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi Jon, > > If people choose not to use this capability or to administratively > > prohibit it, that's fine; just like is done with SNMP sets today. > The MIB could be created as Read-Write and the implementers of the snmp agent could use the AGENT-CAPABILITIES to redefine it as Read-only , if they do not want people to have R/W access to the MIB. Thanks Suresh > > I'm inclined to agree. > > > > I don't do SNMP sets and believe that's the common practice > > among operators today (as Randy mentioned), but can't see > > a good architectural reason to deny this possiblity right > > out of the gate and box ourselves in. > > > > If people choose not to use this capability or to administratively > > prohibit it, that's fine; just like is done with SNMP sets today. > From owner-snmpconf@seymour39.SNMP.COM Mon Dec 18 17:41:53 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16912 for ; Mon, 18 Dec 2000 17:41:53 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id RAA01179 for snmpconf-outgoing; Mon, 18 Dec 2000 17:18:09 -0500 (EST) Message-Id: <200012182218.RAA01172@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 to: snmpconf@snmp.com Subject: snmpconf Re: TE-MIB readonly or read/write Date: Mon, 18 Dec 2000 17:18:07 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Forwarding message bounced due to address change. ------- Forwarded Message Date: Mon, 18 Dec 2000 14:10:53 -0800 Message-Id: <200012182210.OAA25698@mordor.yagosys.com> From: Mike MacFaden To: ben@layer8.net CC: rfrye@longsys.com, te-wg@uu.net, snmpv3@lists.tislabs.com, snmpconf@snmp.com In-reply-to: <20001213101833.D2220@layer8.net> (message from Ben Black on Wed, 13 Dec 2000 10:18:34 -0800) Subject: Re: TE-MIB readonly or read/write Reply-to: mrm@riverstonenet.com >From: Ben Black >could you give examples of large ISPs who are asking for additional >SNMP configuration features? i am not at all a fan of using SNMP for >router configuration, and i believe that puts me in the majority among >service provider engineers. We're putting the cart in front of the horse... Defining a good read-write MIB module does not necessarily imply using *all* the SNMP framework's modules. Per RFC 2570: The specifications of the Internet Standard Management Framework are based on a modular architecture. This framework is more than just a protocol for moving data. It consists of: * a data definition language, * definitions of management information (the Management Information Base, or MIB), * a protocol definition, and * security and administration. [snip] To this end, the framework was architected with a protocol-independent data definition language and Management Information Base along with a MIB-independent protocol. I believe a good read-write MIB module (and I stress good) would be ideal to help define the common mgmt nerd-knobs to be found in a CLI config/show cmd set or other non-IETF standard mgmt interface as well. Regards, Mike MacFaden www.riverstonenet.com ------- End of Forwarded Message From owner-snmpconf@seymour39.SNMP.COM Tue Dec 19 05:38:33 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10441 for ; Tue, 19 Dec 2000 05:38:32 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id FAA22058 for snmpconf-outgoing; Tue, 19 Dec 2000 05:26:27 -0500 (EST) Message-ID: <3A3F379B.F21B6616@mediaone.net> Date: Tue, 19 Dec 2000 05:25:31 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Suresh Krishnan CC: snmpconf@snmp.com, Tony Tauber , Rob Frye , TE Working Group , SNMPv3 Working Group Subject: Re: snmpconf Re: TE-MIB readonly or read/write References: <002701c06925$f6e541a0$b2aea8c0@erilab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > Hi Jon, > > > > If people choose not to use this capability or to administratively > > > prohibit it, that's fine; just like is done with SNMP sets today. > > > The MIB could be created as Read-Write and the implementers of the snmp > agent could use the AGENT-CAPABILITIES to redefine it as Read-only , if they > do not want people to have R/W access to the MIB. > > Thanks > Suresh I think we have a clear consensus among those that have recently commented. Define the MIB module completely including configuration/control objects. There are plenty of standard mechanisms by which vendors and users can use less than the full set of capabilities. /jon From owner-snmpconf@seymour39.SNMP.COM Tue Dec 19 09:04:10 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13723 for ; Tue, 19 Dec 2000 09:04:09 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA28878 for snmpconf-outgoing; Tue, 19 Dec 2000 08:51:38 -0500 (EST) Message-Id: <200012191350.OAA06704@lmera.lmera.ericsson.se> To: TE Working Group , snmpconf@snmp.com Subject: snmpconf Re: TE-MIB readonly or read/write From: David Partain In-reply-to: Your message of Tue, 19 Dec 2000 05:25:31 -0500. <3A3F379B.F21B6616@mediaone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4586.977237445.1@y5m638.lmera.ericsson.se> Date: Tue, 19 Dec 2000 15:50:45 +0100 X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id IAA28874 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com X-MIME-Autoconverted: from 8bit to quoted-printable by seymour39.SNMP.COM id IAA28878 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA13723 Howdy all, I've axed most of the cc'ed folks and reduced it to TE and SNMPCONF. Jon Saperia wrote: > I think we have a clear consensus among those that have > recently commented. Define the MIB module completely including > configuration/control objects. There are plenty of standard > mechanisms by which vendors and users can use less than the > full set of capabilities. I completely agree. Given that we _do_ have a secure way of using SNMP now, I think it would be a mistake not to include read/write objects in the MIB. While some vendors may decide not to implement them read/write, others certainly might want to. In my opinion, the MIB writers shouldn't make that decision for them. With kind regards, -- David Partain David.Partain@ericsson.com Ericsson Radio Systems AB Tel: +46 13 28 41 44 Research and Innovation Fax: +46 13 28 75 67 P.O. Box 1248 SE-581 12 Linköping, Sweden From owner-snmpconf@seymour39.SNMP.COM Tue Dec 19 10:10:13 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15554 for ; Tue, 19 Dec 2000 10:10:13 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA29592 for snmpconf-outgoing; Tue, 19 Dec 2000 09:54:43 -0500 (EST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jon Saperia Cc: Suresh Krishnan , snmpconf@snmp.com, Tony Tauber , Rob Frye , TE Working Group , SNMPv3 Working Group Subject: Re: snmpconf Re: TE-MIB readonly or read/write References: <002701c06925$f6e541a0$b2aea8c0@erilab.com> <3A3F379B.F21B6616@mediaone.net> Message-Id: Date: Tue, 19 Dec 2000 06:54:02 -0800 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > I think we have a clear consensus among those that have recently > commented. the tyranny of the verbose and stubborn? :-) > Define the MIB module completely including configuration/control > objects. There are plenty of standard mechanisms by which vendors and > users can use less than the full set of capabilities. in light of the ccamp mandated separation of measurement and control planes, this rush to judgement might take a bit of a pause. randy From owner-snmpconf@seymour39.SNMP.COM Tue Dec 19 10:59:16 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16771 for ; Tue, 19 Dec 2000 10:59:16 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA00637 for snmpconf-outgoing; Tue, 19 Dec 2000 10:48:14 -0500 (EST) Message-ID: <3A3F830C.94F591B2@mediaone.net> Date: Tue, 19 Dec 2000 10:47:24 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: RJ Atkinson , SNMP Configuration WG , te-wg@uu.net, snmpv3@lists.tislabs.com Subject: snmpconf Re: TE-MIB readonly or read/write References: <5.0.0.25.2.20001218102627.009e8eb0@gnat.inet.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Ran Wrote: > A large part of the reason operators disable/don't use > SNMP SETs is that most managed devices haven't shipped SNMPv3 > with (at least) MD5 authentication yet. The most widely used I wanted to double check before responding. Last I knew, your statement was correct for Juniper. It has not been correct for Cisco for some time. From what I can tell most ISPs have a 12.x that should have these features. > network management platforms DO have SNMPv3 capability today, > either via a 3rd party plug-in (e.g. SNMP Research's module > for HP OpenView) or natively (e.g. Objective Systems' NetExpert > package). True enough. There is also third party code (some of it freeware) that also has full v3 support. > > It would be helpful all around if folks who build boxes > would evangelise within their own employer -- to cause the > implementation (and shipping) of SNMPv3 (with at least MD5 > authentication, preferably both MD5 and DES-CBC) in their > respective boxes. > Agree. /jon From owner-snmpconf@seymour39.SNMP.COM Wed Dec 20 07:42:05 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21654 for ; Wed, 20 Dec 2000 07:42:05 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id HAA29093 for snmpconf-outgoing; Wed, 20 Dec 2000 07:30:02 -0500 (EST) Message-ID: <3A40A60D.670B6010@mediaone.net> Date: Wed, 20 Dec 2000 07:29:01 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Suresh Krishnan , snmpconf@snmp.com, Tony Tauber , Rob Frye , TE Working Group , SNMPv3 Working Group , Jon Saperia Subject: Re: snmpconf Re: TE-MIB readonly or read/write References: <002701c06925$f6e541a0$b2aea8c0@erilab.com> <3A3F379B.F21B6616@mediaone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > > I think we have a clear consensus among those that have recently > > commented. > > the tyranny of the verbose and stubborn? :-) > > > Define the MIB module completely including configuration/control > > objects. There are plenty of standard mechanisms by which vendors and > > users can use less than the full set of capabilities. > > in light of the ccamp mandated separation of measurement and control > planes, this rush to judgement might take a bit of a pause. > > randy > Randy, I was confused by by your comment so I double checked with Scott Bradner to verify my understanding. I believe that the separation you point to is part of a three part plane of management and control functions. There is a desire to standardize two of the three. 1. The first, and lowest layer in this view, is the box to box control protocol. A request to set up a new path, for example. Two cooperating devices would use the protocol to request a new path establishment and probably report certain conditions to the operational software. Using a routing analogy, this would be the exchange of LSAs. Clearly there is benefit to the standardization of such things. 2. The second plane is the 'brains of the operation'. This is the portion that Scott and others believe is best left un-standardized. It is at this layer, that the decision about whether to ask for a new path is made. One vendor may have better heuristics than another and thus might distinguish themselves. Interoperability is not compromised in this regard since the two systems use the layer I described above to communicate the request for a new path. 3. The third plane, and the one that is the only subject for the MIB Modules under discussion is the management plane. This plane has objects for the configuration and control of the behavior of the system. These controls are interpreted by the brains with the resulting behavior on the wire. Also it is at this layer that one would write MIB objects for usage counters and errors for example. I believe the "Define the MIB module completely including configuration/control objects." statement was intended to address only the third plane. The plane that is historically in the management domain. People want to be sure that the interfaces to the external world are standardized, planes one and three, while the middle one is left open for vendor innovation. This approach could equally be applied to routing protocols or other areas of technology. If we are in agreement on these points, then there is no issue unless you do not want configuration and control objects in the MIB Module(s). /jon From owner-snmpconf@seymour39.SNMP.COM Wed Dec 20 13:06:07 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07560 for ; Wed, 20 Dec 2000 13:06:06 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA06007 for snmpconf-outgoing; Wed, 20 Dec 2000 12:48:17 -0500 (EST) Message-Id: <200012201748.MAA06000@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 to: snmpconf@snmp.com Subject: Re: snmpconf Re: TE-MIB readonly or read/write Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 20 Dec 2000 12:48:15 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Forwarding message bounced due to address change. ------- Forwarded Message X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 20 Dec 2000 10:14:26 -0500 To: Jon Saperia From: Bob Natale Subject: Re: snmpconf Re: TE-MIB readonly or read/write Cc: snmpconf@snmp.com, te-wg@uu.net, snmpv3@lists.tislabs.com In-Reply-To: <3A3F379B.F21B6616@mediaone.net> References: <002701c06925$f6e541a0$b2aea8c0@erilab.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 12/19/2000:05:25 AM, Jon Saperia wrote: Hi Jon, >I think we have a clear consensus among those that have recently >commented. I agree...and since, for once, I probably can't be counted among "the verbose and/or stubborn" on a topic, I'd like to add: >Define the MIB module completely including configuration/control >objects. Definitely. >There are plenty of standard mechanisms by which vendors and users >can use less than the full set of capabilities. Right, and given the rest of the informative messages in this thread, we would want to be sure that includes (1) spec'ing with SNMPv3 security capabilities in mind, (2) use of the MIN-ACCESS clause, and (3) use of MODULE-COMPLIANCE macros as may be deemed appropriate by the WGs involved. Thanks, BobN ------- End of Forwarded Message From owner-snmpconf@seymour39.SNMP.COM Thu Dec 28 15:32:41 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19101 for ; Thu, 28 Dec 2000 15:32:40 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA05879 for snmpconf-outgoing; Thu, 28 Dec 2000 15:17:28 -0500 (EST) Message-ID: <3A4BA0C4.C0413068@longsys.com> Date: Thu, 28 Dec 2000 15:21:24 -0500 From: Rob Frye Organization: Longitude Systems, Inc. X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: minutes@ietf.org, SNMPconf Working Group Subject: snmpconf IETF 49 SNMPconf WG notes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit SNMPconf - December 14, 2000 13:00 - 15:00, and December 15, 2000 09:00 - 11:30 Charter: http://www.ietf.org/html.charters/snmpconf-charter.html Chairs: Jon Saperia (saperia@idscons.com) and David Partain (David.Partain@ericsson.com) Agenda was published as http://www.ietf.org/ietf/00dec/snmpconf-agenda.txt, and the only changes made were re-arrangements of topics due to time constraints. The note takers for the sessions were Rob Frye (rfrye@longsys.com), Russell Dietz (rdietz@hifn.com), and Steve Moulton (moulton@snmp.com). David Partain opened the meeting, Blue attendance sheets were circulated. Jon Saperia indicated what the current drafts are, how to join the mailing list, and displayed the agenda. The first day of the meeting had presentation and discussion of the Policy Management MIB with some related discussions about accessors and language features, and the presentation of status on the Configuring Networks and Devices with SNMP BCP. Day two had more accessor and language discussion and a presentation of issues that have arisen in the DiffServ Policy MIB. The text of these meeting notes have been re-arranged to keep the accessor and language items together. Session One: December 14, 2000 13:00 - 15:00 The first document discussed was the Policy Management MIB (draft-ietf-snmpconf-pm-04.txt), presented by Steve Waldbusser. There was much work done on the current version; 5 slides of changes were presented. Some of the significant highlights are: - Scratchpad functions were extended and include scoping, examples of scoping were given. - Parameter tokens $1 through $9 were increased to allow $01 thru $99, and these parameters are available in local variables. - Text was changed to use const" in the document for built-in constants, rather than "#define". - A gap was added in numbering between data types & error codes to allow enough room for future data type expansion. - Added pmPolicyAbnormalTerminations, which counts the number of times that policy execution has failed. - Minimal varbind list length was changed to 32 variables (from 60) for each Policy instance. - Added 64-bit "long long int" integers, getint() modified to return "long int". - Added array derefencing; the contents of octet string objects in strings can now be returned and a way was needed to access binary data in octet strings. - Added support for Strings. - Filter scripts execute immediately when network elements are discovered; action scripts execute immediately when its related Filter evaluates TRUE. - A script code table was added for scripts that are larger than the MTU; multiple SNMP sets will be needed to build the script, then reference it in the other MIBs to trigger its execution. - Added newCapability & newRole notifications, add registration table for managers to receive these notifications. - A description of the handling of SNMP errors was added. - New BNF was defined to account for the various changes made; there may be some discussion of the BNF on the mailing list. - ISO C, not ANSI C (X3J11), will be used as the standard language definition; with the addition of String support, there was some discussion about making C++ the standard language definition though conclusion was reached that C should continue to be the standard reference, due to concerns about needing to make it simple so implementation on embedded platforms would be possible. This may not be relevant, as the BNF describes a subset of C or C++ anyway. - A question was raised about whether this language definition & SMING should be combined, or at least use the SMIng functions in the SNMPconf language. However, SMING is data definition oriented, whereas the SNMPconf policy language is operator oriented, which makes SMING inappropriate at present for the SNMPconf expression language. Furthermore, because of the state of SMING, it is not yet possible for SNMPconf drafts to make reference to SMING documents, other than as "works in progress". Therefore, between the C/C++ issues and SMING issues, we should stick with the C reference and then add the items we need from C++. There may be further discussion on the list about this, if anyone disagrees with this approach. There was a question on the example given of pmPolicyAbnormalTerminations that led to the conclusion that more clarifying text is needed. There was some discussion about the notification registration table, as to whether it is like RFC 2573's trapFilterTable & trapForwardingTable [correction: snmpNotifyFilterTable and snmpNotifyTable, respectively]. Although there are similarities, the RFC 2573 tables are not appropriate, as the snmpNotifyFilterTable is based on an information bus model; all traps from all sources go thru that table. This did not reach satisfactory conclusion and will be considered & discussed further on the mailing list. Similar discussion was related to the code table vs VACM in SNMPv3. No satisfactory conclusion was reached and this topic will be considered & discussed further on the mailing list. Some Security issues were discussed and will be added into the draft. In particular, dealing with SNMP actions in scripts - how security parameters are to the SNMP calls, and Mid-level manager inherited access writes - how to decide which security parameters to use. Policy Grouping for precedence was discussed, particularly that we ensure that when a policy is no longer valid, rather than waiting for "max latency" time to expire, when Policy C terminates and "uncovers" Policy B, that B would execute immediately. To accomplish this, an "on exit" clause was discussed so that policies would go to a "quiescent" state when the policy is no longer in effect, and use precedence & grouping so that a "normal" policy runs all the time when some higher-priority policy is NOT running. Error conditions need to be considered, where setting of some variables depend on other settings elsewhere. Policies run while the schedule indicates the policy is active and are dormant otherwise; some sets of policies are interrelated and these sets of policies should be turned on and off in tandem. Edge triggered versus level triggered scheduling (with addition of duration) was discussed to accomplish this; using edge-triggered scheduling, pairs of scheduleEntry's would be needed to accomplish one schedule although the addition of duration is not sufficient to provide sufficient level-triggered semantics. It was agreed that level-triggered scheduling is desired. There are unreliable semantics regarding when multiple, potential overlapping schedules touch a policy; consensus was that we probably want the semantic that the policy is active if ANY associated schedule is active. There was some discussion about whether the DisMan ScheduleMIB would provide the needed functionality, or if we could use it and change the meaning of certain objects when used with the Policy management MIB - it was agreed that this could result in confusion. The difficulty in having one policy clean up from another was discussed, with the possibility of having the scheduler do some cleanup (ie, do more than simple scheduling, such as be a "schedule guardian" or "ober-scheduler"). No matter what happens, the new policy must be able to determine the result. Based on the concerns outlined by Steve in his presentation, Jon Saperia presented a new pmSchedTable to the group designed to address these concerns. This will be the basis for another revision of the draft. Further work is needed in the scheduling (pmSchedTable) area. Possible future draft changes include adding "pass by reference" and automatic initialization, to be discussed further on the list as needed. The next document was Configuring Networks and Devices with SNMP (draft-ietf-snmpconf-bcp-03.txt), presented by Wayne Tackabury. Some highlights of that presentation: - The scope was clarified, text was thoroughly reorganized, examples were expanded & clarified. The scope of the draft is to provide guidance on current practices using SNMP for configuration, focusing on using SNMPv3 and to provide the groundwork for policy- based SNMP configuration. The draft provides guidance for ISP Operators in SNMP deployment practices and configuration change diagnostics, guidance to agent/MIBmodule developers for developing coherent and scalable settable row objects and other features, and guidance to management station developers in implementing transactional semantics. - A request was made for text to be contributed describing how some agent implementions do a lot of things incorrectly and how management stations can cope with these poor agent implementations. - The current draft needs WG review and further editing; particularly security issues discussion. The plan is to go to WG last call after IETF 50 while avoiding scope creep. It is intended for Standards-track as BCP. Session Two: December 15, 2000 09:00 - 11:30 With some examples from the Policy Management MIB, Steve Waldbusser led the discussion of Accessor Functions and Language Issues. Language and Accessor Function issues included the following. - In the Accessor Functions discussions (particularly in the first session), several examples were given, both simple (involving simple settings of integers) and complex (setting up RMON2 alMatrix monitoring). These examples were used to show flaws of certain approaches and the use of the searchColumnEntry or storing the OID/index in the scratchpad between invocations. - There was some discussion about how resource cleanup would occur, particularly considering that there is no automatic garbage collection. No solution was reached in the meeting and may be discussed further on the mailing list. - It was generally agreed to do "pass by reference" so that "&" is not needed when passing parameters to accessor functions. - Automatic, non-default, initialization was added. This occurs whenever a script becomes active. - There was considerable discussion about the need to support both createAndWait or createAndGo operations. The group consensus was that both createAndWait and createAndGo should be provided. - The createAndWait/createAndGo discussion led into a discussion of the staging of building PDUs to send (or parsing/reading received PDUs) - whether by passing of varbinds 1 at a time vs a "varargs" approach. There was no clear consensus, so a small design team (Steve Waldbusser, Juergen Schoenwalder) will consider the possible approaches for building PDUs, including PDUs as objects with operator overloading. - The next significant discussion was whether or not to add a "setCli()" function to interact with command line interface mechanisms (analogous to the "system" function call on Unix). Major concerns are of it being used in heterogeneous environments, it is ugly and goes against standards although is very practical, the numerous security issues (eg: how to map SNMP context to "login" equivalent), etc. Many reasons were given for doing so (even by those who would prefer not to), and many reasons against it. No consensus was reached, so we decided that this is to be investigated further - it was agreed that it's a bad thing to do, that the benefits may not outweigh the bad things. We will continue discussion on the list. Policy Grouping discussions were next. The policyGroup & policyPrecedence semantics have not been worked out entirely, although in general lower numbered precedence value gives higher priority within a group, and the highest precedence policy whose filter allows it to run at a given time "wins". Time- ordering of policies within a group may be critical. It was agreed that any particular policy (action) should run as an atomic transaction. An entire policyGroup should be considered as a single logical policy, such that all policies are running at once, depending on what filters trigger for given elements. Some discussion was done regarding booting/startup. Specifically, any policy not in a group can fire immediately, within its schedule, and for those in a group, no Policy can run, except for the highest Precedence policy, until all filters for all policies in the group have been evaluated. More discussion took place on the issue of what to do on "policy replacement" - what to do when PolicyB trumps PolicyA, B runs, then B terminates. The conclusion was that it is necessary to immediately re-evaluate A's filter & schedule to determine if PolicyA's actions need to be invoked. This leads to different windows of evaluating precedence and filters, and deciding appropriate actions. Filters should be rechecked immediately when precedence changes, new policies are added, or old policies are deleted. It was agreed that this needs further consideration on the list. The next draft discussed was The DiffServ Policy MIB (draft-ietf-snmpconf-diffpolicy-03.txt), presented by Harrie Hazewinkel and Bob Moore. Harrie gave some background of what DiffServ is all about, then used the diffServDataPathTable in DIFFSERV-MIB as a starting point for SNMPconf policy-management discussions. The DIFFSERV-POLICY-MIB is used to create templates with classifier, meter, actions drop, mark, and count using the diffPolicyDPCTable. A Policy example was used for providing gold service, applying EF marking to packets from certain customers. Obsoleted entries could be garbage collected, which is not currently defined in standard. There are further issues related to garbage collection, such as being able to tell if something SHOULD be GC'd. The conclusion was reached that we need to use template cloning with a single SNMP Set to build the right diffserv policy, although that leads to further problems with RowPointers. Bob Moore then continued the discussion showing the difficult interactions between Templates & RowPointers. The advantages of this approach for doing data path parameterization was shown, and it was shown that duplicating Templates does not require duplicating parameterizations. It was determined to be necessary to identify in Templates what needs a new row (new object to point to) vs re-using the same object as in copied-from row(s). There is no simple answer to this; an example next-order problem was shown with "fan-out/fan-in" linkages, with the desire to share a new single instance rather than duplicating instances. The current diffserv MIB has only StaticRowPointers which point "outside" of the template; it doesn't have dynamic RowPointers. It was suggested that an appropriate approach might be to not focus on the RowPointers, but on the pointed-to objects via a new kind of TextualConvention, which would have the negative effect of combining 2 distinct operations together: copy & clone vs the value & use of the objects. There are 2 steps involved: generating (creating the new row & new OID) or reusing (referencing the row by copying the OID), and determining how to plug in the relevant information to referencing tables. An ID has been submitted into the Management and Operations area with 2 new TCs to handle these template conditions. However, that draft will likely be modified and re-submitted (on the MIBs list) with just the one TC that describes new behavior, not currently available with the definition of RowPointer operations. Meanwhile, the DiffServe WG is moving ahead with their approach in case the generalized ID doesn't become an RFC in time. It was agreed that between now & the next IETF (IETF 50, March 2001), the diffserv examples will be updated by David Partain. To wrap up the meeting, Rob Frye agreed to distribute notes to the WG list not later than 12/22/2000 [note: they are being sent to Chairs on 12/25/2000]. There will be further discussion on the mailing list for at most 2 weeks about the need for an interim meeting before IETF 50 in March to discuss topics such as the "setCLI" function. We agreed to see how much can be done on list first, then hold an interim meeting if we do not reach consensus. The existing charter says that we will conclude our work by IETF 50 in March 2001. -- // Rob. Rob Frye Director, Software Development Longitude Systems, Inc. 15000 Conference Center Drive Chantilly, VA 20151 www.longsys.com voice: +1-703-818-5426 fax: +1-703-961-8751 mobile: +1-703-725-1130 email: rfrye@longsys.com From owner-snmpconf@seymour39.SNMP.COM Thu Dec 28 16:09:58 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19500 for ; Thu, 28 Dec 2000 16:09:58 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA06803 for snmpconf-outgoing; Thu, 28 Dec 2000 15:54:49 -0500 (EST) Date: Thu, 28 Dec 2000 12:53:11 -0800 (PST) From: Randy Presuhn Message-Id: <200012282053.MAA06247@dorothy.bmc.com> To: snmpconf@snmp.com Subject: Re: snmpconf IETF 49 SNMPconf WG notes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com X-MIME-Autoconverted: from 8bit to quoted-printable by seymour39.SNMP.COM id PAA06803 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA19500 Hi - > Message-ID: <3A4BA0C4.C0413068@longsys.com> > Date: Thu, 28 Dec 2000 15:21:24 -0500 > From: Rob Frye > Organization: Longitude Systems, Inc. > To: minutes@ietf.org, SNMPconf Working Group > Subject: snmpconf IETF 49 SNMPconf WG notes ... > - A question was raised about whether this language > definition & SMING should be combined, or at least use > the SMIng functions in the SNMPconf language. However, SMING is data > definition oriented, whereas the SNMPconf policy language is operator > oriented, which makes SMING inappropriate at present for the > SNMPconf expression language. Furthermore, because of the state of > SMING, > it is not yet possible for SNMPconf drafts to make reference to SMING > documents, other than as "works in progress". Therefore, between the > C/C++ > issues and SMING issues, we should stick with the C reference and then > add > the items we need from C++. There may be further discussion on the list > > about this, if anyone disagrees with this approach. ... The question was how / whether SMING data types would be referenced from the scripting language, not whether the languages should somehow be combined. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. -------------------------------------------------------