From owner-snmpconf@seymour39.SNMP.COM Wed Jan 2 10:03:25 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05227 for ; Wed, 2 Jan 2002 10:03:23 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA06687 for snmpconf-outgoing; Wed, 2 Jan 2002 09:51:11 -0500 (EST) Message-Id: <200201021451.JAA27256@seymour164.snmp.com> to: snmpconf@snmp.com Subject: snmpconf quarterly list instructions mailing Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 02 Jan 2002 09:51:08 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit The snmpconf list is for discussing the business of the Configuration Management using SNMP (snmpconf) working group of the IETF. This working group is an open forum for raising and discussing issues related to network device configuration management and SNMP. To remove yourself from the snmpconf discussion list, send a message to snmpconf-request@majordomo.snmp.com containing just the word unsubscribe in the message body (not in the subject). A http archive is available at http://www.snmp.com/snmpconf/mailing-list/index.html Please send any questions or comments about the management of this list to owner-snmpconf@majordomo.snmp.com. From owner-snmpconf@seymour39.SNMP.COM Wed Jan 9 20:50:43 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24042 for ; Wed, 9 Jan 2002 20:50:43 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id UAA29046 for snmpconf-outgoing; Wed, 9 Jan 2002 20:39:53 -0500 (EST) Date: Wed, 9 Jan 2002 17:37:38 -0800 (PST) From: Randy Presuhn Message-Id: <200201100137.RAA13915@dorothy.bmc.com> To: snmpconf@snmp.com Subject: snmpconf IPR notification 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 Hi - It's come to my attention that BMC Software has some intellectual property that may be related to the work in the snmpconf WG. We are still investigating the extent of the relationship and have not made any final decision on the licensing issues, but, pursuant to RFC 2026, our legal folk (and Bert) have asked that I forward this notice to the working group. We're just trying to be good citizens here, and I'll keep you posted of relevant further developments. > This is to advise the IETF that BMC Software Inc. ("BMC > Software") believes that it has rights in one or more United > States or foreign patents or pending patent applications, > including but not limited to U.S. Patent No. 5,978,594 > and/or U.S. Patent No. 5,665,081, that may relate to > technologies and processes discussed in the Internet Draft > draft-ietf-snmpconf-pm-xx, including but not limited to > technologies and/or processes for which employees of BMC > Software may have contributed information. BMC Software may > also seek patent protection for any such technology or other > information if BMC Software concludes that such protection > is warranted. Parties interested in obtaining information > regarding any such license from BMC Software should contact: > > Ken Sidelinger > Senior Legal Counsel - Intellectual Property > BMC Software, Inc. > o: (713) 918-1259 > f: (713) 918-1110 > e: ken_sidelinger@bmc.com ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-snmpconf@seymour39.SNMP.COM Thu Jan 10 09:37:49 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15552 for ; Thu, 10 Jan 2002 09:37:49 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA19529 for snmpconf-outgoing; Thu, 10 Jan 2002 09:29:04 -0500 (EST) Organization: NeST-India Message-ID: <273ED687CFB4D411986100306E0013BC01489358@pdc1.nestec.net> From: RAM MOHAN To: snmpconf@snmp.com Subject: snmpconf naive question on SNMP Date: Thu, 10 Jan 2002 19:51:41 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Excuse me Does anyone know an instance of SNMP being used for monitoring general purpose software (applications) running in remote hosts from a central management station? Are there standard MIBs and agents already developed for application monitoring? Any tips / links / newsgroups where I can pose this query? Thank you for your time. Ram Mohan From owner-snmpconf@seymour39.SNMP.COM Thu Jan 10 15:26:47 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23271 for ; Thu, 10 Jan 2002 15:26:47 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id PAA01697 for snmpconf-outgoing; Thu, 10 Jan 2002 15:16:34 -0500 (EST) From: Jeff Case Date: Thu, 10 Jan 2002 15:16:29 -0500 (EST) Message-Id: <200201102016.PAA14653@seymour4.snmp.com> To: snmpconf@snmp.com Subject: Re: snmpconf naive question on SNMP Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >Excuse me hello >Does anyone know an instance of SNMP being used for monitoring general >purpose software (applications) running in remote hosts from a central >management station? yes, there are we have a number of customers who do this, which is typically done on mission-critical servers such as file servers, print servers, web servers, security servers, name servers, etc as opposed to ordinary desktops >Are there standard MIBs and agents already developed for application >monitoring? yes, there are some of the standard mib documents include: rfc 2790 host resources mib rfc 2287 system applications mib rfc 2564 application management mib as well as a number of more mib modules related to specific applications such as relational data bases, web servers, etc several vendors offer agent products that implement these mib modules >Any tips / links / newsgroups where I can pose this query? i am glad you asked this, because this is not really the right mailing list host resources mib: ... In addition, the Host Resources MIB mailing list is dedicated to discussion of this MIB. To join the mailing list, send a request message to hostmib-request@andrew.cmu.edu. The mailing list address is hostmib@andrew.cmu.edu." ... (but really pretty inactive) system applications mib and applications mib applmib-request@verio.net or check with carl, cwk@verio.net >Thank you for your time. you are welcome best regards, jdc From owner-snmpconf@seymour39.SNMP.COM Fri Jan 11 20:23:39 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04160 for ; Fri, 11 Jan 2002 20:23:37 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id UAA09987 for snmpconf-outgoing; Fri, 11 Jan 2002 20:12:39 -0500 (EST) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> From: "Glenn Waters" To: snmpconf@snmp.com Subject: Review of draft-ietf-snmpconf-bcp-07 Date: Fri, 11 Jan 2002 20:11:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19B06.21C014F0" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19B06.21C014F0 Content-Type: text/plain; charset="iso-8859-1" Sorry this is late and past the end of the WG last call. I find that there is a great deal of good information in this document. It is a monumental task to write about so many complex network management topics in a single IETF document -- a book would be hard pressed to present so much information. Let me start with a few general comments about the document. First, I have a hard time with the classification of this document as a BCP. There is some BCP content but there is also content that is Experimental, Informational, and, some which should be put into a standard. I point out some of those sections as I went through. Second, there are some sections of the document that seem to gloss over the detail. Sections 4 and 5 are notable examples where the concepts are hastily presented and conclusions on how to deal with the issue is light on detail. I found reviewing these sections very difficult since if I were to write anything then I would have to spend a huge amount of time giving the feedback. I do note that the topics in those sections are very complexity and I can understand why I feel that they are light. I am not sure how or if they should fit into this document. Third, and this doesn't have so much to do with this document as it does with SNMP configuration management in general, it's no wonder people don't do configuration management using SNMP. Given the amount of information presented in this document (and for the most part its good information), the complexity of implementing configuration management using SNMP is well beyond many development organizations. I consider myself reasonable experienced in this area and I find that I would have a hard time developing a system that could reasonably be configured using the SNMP. Not many organizations have experienced SNMP developers to the level of some of the techniques that are presented here. CLI looks so very inviting after reading all the tricks, tips, and details that one must consider. Finally, I did not review section 8. Onto some specifics: ---- [page 5] 2.2. Practical Requirements for Transactional Control This section was overly vague and I am not sure exactly what the I am to take away from information. There is some good general information but nothing that is specific enough that I could use it -- especially in the context of a BCP. ---- [page 10] Object descriptors (the "human readable names" assigned to object iden- tifiers [5]) defined in standard MIB modules should be unique across all MIB modules. Not sure that this is possible, desirable, or required. I think that being unique within a MIB module is just fine. Besides, vendors MIBs will likely use a name that is being used by some other module. ---- [page 10] Secondly, management applications can be pointed at specific subtrees for fault or configura- tion, causing a more efficient retrieval of data and a simpler manage- ment application with potentially better performance. I don't get this point which is in the section called "Naming MIB Modules and Managed Objects". How does naming objects have anything to do with the OID tree structure? ---- [page 12] 3.3.3. Transaction Control MIB Objects This section should be merged with section 3.12. This section (3.3.3) is vague and section 3.12 has some better detail to help understand the concept. ---- [page 14] RowStatus object when the row under creation does not yet have all of the required, non-defaultable instance values for the row. One approach to simplifying in-row configuration transactions when designing MIB mod- ules is to construct table rows that have no more instance data for columnar objects than will fit inside a single SET PDU. In this case, the createAndWait() value for the RowStatus columnar object is not required. It is possible to use createAndGo() in the same SET PDU, thus simplifying transactional management. It is also possible for an MIB to say "the agent must support a minimum PDU size of 'X'" where X is big enough to contain all the columns of a new row. This would ensure that an entire row fits in a PDU. ---- [page 27] An example of such an object from the OSPF Version 2 MIB [27] is the global ospfAdminStat: ospfAdminStat OBJECT-TYPE SYNTAX Status MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative status of OSPF in the router. The value 'enabled' denotes that the OSPF Process is active on at least one inter- face; 'disabled' disables it on all inter- faces." ::= { ospfGeneralGroup 2 } This object does not seem to match the discussion from the previous paragraphs. The point that I get from the section is that you are describing how to activate parts of a configuration. It seems that this object is activating a process which uses some configuration. I thought that you would present an object that controls some part of the configuration. ---- [page 32] INFORM PDUs, as opposed to TRAP PDUs, have an inherent advantage when the concern is the reduction of unneccessary messages from the system generating the NOTIFICATION-TYPE data. I don't understand what the inherent advantage is. This statement could use some clarification. ---- [page 39] 4.1. Operational Consistency I read this section a number of times and the text seems more like a thesis than a BCP document. There is some good information in the section but there I think that the information would only give me some food for thought when designing the system and would not give me concrete ideas on my design. ---- [page 41] 4.2. Handling Multiple Managers This topic is very complex and has very little explanation. I am not comfortable with what is presented. Maybe a one liner somewhere else in the document that says something to the effect that "managers could consider methods of providing redundancy for each other when possible" (similar to the last sentence in the paragraph). ---- [page 42] 1. A method for restoring a previous configuration to one or more devices. Ideally this restoration should be time indexed so that a network can be restored to a configured state as of a specific time and date. 2. A method for saving back up versions of the configuration data in case of hardware or software failure. 3. A method of providing fail-over to a secondary (management) system in case of a primary failure. This capability should be These are not BCP but are requirements of a management station solution. Good stuff to think about but not in the context of a BCP. ---- [page 43] - Ensure minimum movement of data Minimum movement of data does not stand alone as a general management application design. It needs to be traded off against CPU, bandwidth, application complexity, etc. ---- [page 44] Management software should be mindful of the environment in which SET operations are being deployed. The intent here is to move configuration information as efficiently to the managed device as possible. There are many ways to achieve efficiency and some are specific to given devices. One general case that all management software should employ is to reduce the number of SET PDU exchanges between the managed device and the man- agement software to the smallest reasonable number. One approach to this is to verify the largest number of variable bindings that can fit into a SET PDU for a managed device. In some cases, the number of variable bindings to be sent in a particular PDU will be influenced by the device, the specific MIB objects and other factors. I'm not sure what to do with this paragraph. There are some true and valid points but the paragraph ends on a very vague not saying "and other factors". This document is supposed to help those who don't know. I think I knew, but I have not figured out what the other factors are. ---- [page 44] Maximizing SET variable bindings within a PDU has beneficial implica- tions in the area of management application transaction initiation, as well, as we will discuss in the following section. Parse error. I think I get the meaning. Could it not be said a whole lot simpler -- or not said at all -- let the following section talk about it. ---- [page 44] Yet there are agents that may have implementation limitations on the number and order of varbinds it can handle in a single SET PDU. In this case, sending fewer varbinds will be necessary. Good information. How am I supposed to write the management application? How do I determine that I have a "broken" agent? ---- [page 44] Some SNMP agents implement a subset of the features available and so the management application must avoid using features that may not be supported in a specific table implementa- tion, such as createAndWait. Good information. How am I supposed to write the management application? How do I determine that I have an agent with partial support for a standard? ---- [page 46] 5.2.3. Notifications As described throughout the section on Agent Software Development, agents should provide the capability for notifications to be sent to their configured management systems whenever a configuration operation is attempted or completed. The management application must be prepared to accept these notifications so that it knows the current configured state of the devices it has been deployed to control. Some configura- tion management applications may consume data from the managed devices that reflect configuration, operational and utilization state informa- tion. The GetBulkRequest-PDU is useful here whenever supported by the managed device. For the purposes of backward compatibility, the manage- ment station should also support and make use of the GetNextRequest-PDU in these cases. I am missing the point here. First what does getBulk have to do with notifications? I think the point around get* should be in a separate section that deals with retrieving lots of data from a box. ---- [page 46] 5.2.4. Scalability of Data Retrieval Efficient data retrieval described above is only part of the dimension of scale that application developers should consider when developing configuration applications. Management applications should provide for distributed processing of the configuration operations. This also extends to other management functions not the focus of this document. This capability can also be used to provide resilience in the case of network failures as well. An SNMP-based configuration management system might be deployed in a distributed fashion where three systems in dif- ferent locations keep each other synchronized. This synchronization can be accomplished without additional polling of network devices through a variety of techniques between each of the three managers. In the case of a failure, a 'backup' system can take over the configuration responsi- bilities of the failed manager without having to re-synchronize with the managed elements since it will already be up to date. This section sounds very experimental to me. ---- [page 49] 7. POLICY BASED MANAGEMENT Not sure how policy management is BCP. ---- [page 50] - there is the ability to specify "default" configuration data for a number of instances of managed elements, where those instances can be correlated in some data driven or algorithmic way. The engine to do this correlation and activate instances from defaults may reside in the agent or externally. Where the representation of these defaults are in the MIB design itself, the object types supporting this notion are referred to as "template objects". The notion of template objects is introduced here. What I do not understand is why is the concept of template objects not used in draft-ietf-snmpconf-pm-09.txt? We need some consistency of terminology whether it is in this document or in the policy MIB document. Seems like this is a new concept that needs more vetting than what is being done in this document. Once again, the information is interesting and somewhat good just misplaced. ---- General edits... s/internet/Internet/ s/implementors/implementers/ s/accomodate/accommodate/ s/indesx/indexes/ s/variable bindings/varBinds/ -- this would improve some of the readability From page 5 of RFC 2223: Do not do hyphenation of words at the right margin. Cheers, /gww ------_=_NextPart_001_01C19B06.21C014F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-snmpconf-bcp-07

Sorry this is late and past the end of the WG last = call.

I find that there is a great deal of good information = in this document. It is a monumental task to write about so many = complex network management topics in a single IETF document -- a book = would be hard pressed to present so much information.

Let me start with a few general comments about the = document.

First, I have a hard time with the classification of = this document as a BCP. There is some BCP content but there is also = content that is Experimental, Informational, and, some which should be = put into a standard. I point out some of those sections as I went = through.

Second, there are some sections of the document that = seem to gloss over the detail. Sections 4 and 5 are notable examples = where the concepts are hastily presented and conclusions on how to deal = with the issue is light on detail. I found reviewing these sections = very difficult since if I were to write anything then I would have to = spend a huge amount of time giving the feedback. I do note that the = topics in those sections are very complexity and I can understand why I = feel that they are light. I am not sure how or if they should fit into = this document.

Third, and this doesn't have so much to do with this = document as it does with SNMP configuration management in general, it's = no wonder people don't do configuration management using SNMP. Given = the amount of information presented in this document (and for the most = part its good information), the complexity of implementing = configuration management using SNMP is well beyond many development = organizations. I consider myself reasonable experienced in this area = and I find that I would have a hard time developing a system that could = reasonably be configured using the SNMP. Not many organizations have = experienced SNMP developers to the level of some of the techniques that = are presented here. CLI looks so very inviting after reading all the = tricks, tips, and details that one must consider.

Finally, I did not review section 8.

Onto some specifics:

----

[page 5]
        2.2.  Practical Requirements for Transactional = Control

This section was overly vague and I am not sure = exactly what the I am to take away from information. There is some good = general information but nothing that is specific enough that I could = use it -- especially in the context of a BCP.

----

[page 10]
        Object = descriptors (the "human readable names" assigned to object = iden-
        tifiers = [5]) defined in standard MIB modules should be unique across all
        MIB = modules. 

Not sure that this is possible, desirable, or = required. I think that being unique within a MIB module is just fine. = Besides, vendors MIBs will likely use a name that is being used by some = other module.

----

[page 10]
        Secondly, = management
        applications can be pointed at specific subtrees for fault or = configura-
        tion, = causing a more efficient retrieval of data and a simpler manage-
        ment = application with potentially better performance.

I don't get this point which is in the section called = "Naming MIB Modules and Managed Objects". How does naming = objects have anything to do with the OID tree structure?

----

[page 12]
        3.3.3.  Transaction Control MIB Objects

This section should be merged with section 3.12. This = section (3.3.3) is vague and section 3.12 has some better detail to = help understand the concept.

----

[page 14]
        RowStatus = object when the row under creation does not yet have all of
        the = required, non-defaultable instance values for the row.  One = approach
        to = simplifying in-row configuration transactions when designing MIB = mod-
        ules is = to construct table rows that have no more instance data for
        columnar = objects than will fit inside a single SET PDU.  In this = case,
        the = createAndWait() value for the RowStatus columnar object  is = not
        required.  It is possible to use createAndGo() in the = same SET PDU, thus
        simplifying transactional management.

It is also possible for an MIB to say "the agent = must support a minimum PDU size of 'X'" where X is big enough to = contain all the columns of a new row. This would ensure that an entire = row fits in a PDU.

----

[page 27]
        An = example of such an object from the OSPF Version 2 MIB [27] is = the
        global = ospfAdminStat:

            ospfAdminStat OBJECT-TYPE
        =         SYNTAX   Status
        =         MAX-ACCESS   read-write
        =         STATUS   current
        =         DESCRIPTION
        =            = "The  administrative  status  of  OSPF  = in  the
        =            = router.   The  value 'enabled' denotes that the
        =            = OSPF Process is active on at least  one  inter-
            &= nbsp;      face;  = 'disabled'  disables  it  on  all inter-
        =            = faces."
               ::=3D { ospfGeneralGroup = 2 }

This object does not seem to match the discussion = from the previous paragraphs. The point that I get from the section is = that you are describing how to activate parts of a configuration. It = seems that this object is activating a process which uses some = configuration. I thought that you would present an object that controls = some part of the configuration.

----

[page 32]
        INFORM = PDUs, as opposed to TRAP PDUs, have an inherent advantage when
        the = concern is the reduction of unneccessary messages from the = system
        generating the NOTIFICATION-TYPE data.

I don't understand what the inherent advantage is. = This statement could use some clarification.

----

[page 39]
        4.1.  Operational Consistency

I read this section a number of times and the text = seems more like a thesis than a BCP document. There is some good = information in the section but there I think that the information would = only give me some food for thought when designing the system and would = not give me concrete ideas on my design.

----

[page 41]
        4.2.  Handling Multiple Managers

This topic is very complex and has very little = explanation. I am not comfortable with what is presented. Maybe a one = liner somewhere else in the document that says something to the effect = that "managers could consider methods of providing redundancy for = each other when possible" (similar to the last sentence in the = paragraph).

----

[page 42]
          1. = A method for restoring a previous configuration to one or
          = more devices. Ideally this restoration should be time indexed
          so = that a network can be restored to a configured state as of
          a = specific time and date.

          2. = A method for saving back up versions of the configuration
          = data in case of hardware or software failure.

          3. = A method of providing fail-over to a secondary (management)
          = system in case of a primary failure. This capability should be

These are not BCP but are requirements of a = management station solution. Good stuff to think about but not in the = context of a BCP.

----

[page 43]
        -    Ensure minimum movement of data

Minimum movement of data does not stand alone as a = general management application design. It needs to be traded off = against CPU, bandwidth, application complexity, etc.

----

[page 44]
        Management software should be mindful of the environment in = which SET
        operations are being deployed. The intent here is to move = configuration
        information as efficiently to the managed device as = possible.  There are
        many ways = to achieve efficiency and some are specific to given devices.
        One = general case that all management software should employ is to = reduce
        the = number of SET PDU exchanges between the managed device and the = man-
        agement = software to the smallest reasonable number. One approach to this
        is to = verify the largest number of variable bindings that can fit into = a
        SET PDU = for a managed device. In some cases, the number of variable
        bindings = to be sent in a particular PDU will be influenced by the
        device, = the specific MIB objects and other factors.

I'm not sure what to do with this paragraph. There = are some true and valid points but the paragraph ends on a very vague = not saying "and other factors". This document is supposed to = help those who don't know. I think I knew, but I have not figured out = what the other factors are.

----

[page 44]
        Maximizing SET variable bindings within a PDU has beneficial = implica-
        tions in = the area of management application transaction initiation, as
        well, as = we will discuss in the following section.

Parse error.
I think I get the meaning. Could it not be said a = whole lot simpler -- or not said at all -- let the following section = talk about it.

----

[page 44]
        Yet there = are agents that may have implementation limitations on the
        number = and order of varbinds it can handle in a single SET PDU.  In = this
        case, = sending fewer varbinds will be necessary.

Good information. How am I supposed to write the = management application? How do I determine that I have a = "broken" agent?

----

[page 44]
        Some SNMP = agents implement a subset
        of the = features available and so the  management application must = avoid
        using = features that may not be supported in a specific table = implementa-
        tion, = such as createAndWait.

Good information. How am I supposed to write the = management application? How do I determine that I have an agent with = partial support for a standard?

----

[page 46]
        5.2.3.  Notifications
        As = described throughout the section on Agent Software Development,
        agents = should provide the capability for notifications to be sent to
        their = configured management systems whenever a configuration operation
        is = attempted or completed.  The management application must be = prepared
        to accept = these notifications so that it knows the current configured
        state of = the devices it has been deployed to control.  Some = configura-
        tion = management applications may consume data from the managed = devices
        that = reflect configuration, operational and utilization state = informa-
        tion. The = GetBulkRequest-PDU is useful here whenever supported by the
        managed = device. For the purposes of backward compatibility, the manage-
        ment = station should also support and make use of the = GetNextRequest-PDU
        in these = cases.

I am missing the point here. First what does getBulk = have to do with notifications? I think the point around get* should be = in a separate section that deals with retrieving lots of data from a = box.

----

[page 46]
        5.2.4.  Scalability of Data Retrieval

        Efficient = data retrieval described above is only part of the dimension
        of scale = that application developers should consider when developing
        configuration applications. Management applications should = provide for
        distributed processing of the configuration operations. This = also
        extends = to other management functions not the focus of this document.
        This = capability can also be used to provide resilience in the case of
        network = failures as well. An SNMP-based configuration management system
        might be = deployed in a distributed fashion where three systems in dif-
        ferent = locations keep each other synchronized. This synchronization can
        be = accomplished without additional polling of network devices through = a
        variety = of techniques between each of the three managers. In the case of
        a = failure, a 'backup' system can take over the configuration = responsi-
        bilities = of the failed manager without having to re-synchronize with the
        managed = elements since it will already be up to date.

This section sounds very experimental to me.

----

[page 49]
        7.  = POLICY BASED MANAGEMENT

Not sure how policy management is BCP.

----

[page 50]
            - there is the ability to specify = "default" configuration data for a
              number of instances of managed = elements, where those instances can
              be correlated in some data = driven or algorithmic way.  The engine
              to do this correlation and = activate instances from defaults may
              reside in the agent or = externally.  Where the representation of
              these defaults are in the MIB = design itself, the object types
              supporting this notion are = referred to as "template objects".

The notion of template objects is introduced here. = What I do not understand is why is the concept of template objects not = used in draft-ietf-snmpconf-pm-09.txt? We need some consistency of = terminology whether it is in this document or in the policy MIB = document. Seems like this is a new concept that needs more vetting than = what is being done in this document. Once again, the information is = interesting and somewhat good just misplaced.

----

General edits...

s/internet/Internet/
s/implementors/implementers/
s/accomodate/accommodate/
s/indesx/indexes/
s/variable bindings/varBinds/ -- this would improve = some of the readability

From page 5 of RFC 2223:
      Do not do hyphenation = of words at the right margin.

Cheers, /gww

------_=_NextPart_001_01C19B06.21C014F0-- From owner-snmpconf@seymour39.SNMP.COM Fri Jan 11 21:07:50 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04468 for ; Fri, 11 Jan 2002 21:07:49 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id UAA10193 for snmpconf-outgoing; Fri, 11 Jan 2002 20:59:36 -0500 (EST) Date: Fri, 11 Jan 2002 17:59:00 -0800 From: Michael MacFaden To: snmpconf@snmp.com Subject: Re: Review of draft-ietf-snmpconf-bcp-07 Message-ID: <20020111175900.K1364@riverstonenet.com> References: <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com>; from gww@nortelnetworks.com on Fri, Jan 11, 2002 at 08:11:58PM -0500 X-Operating-System: GNU/Linux 2.4.16 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Glen, Thanks very much for the detailed review as well as the impression the document left you with. Below are some comments... Regards, Mike On Fri, Jan 11, 2002 at 08:11:58PM -0500, Glenn Waters wrote: >First, I have a hard time with the classification of this document as a BCP. >There is some BCP content but there is also content that is Experimental, >Informational, and, some which should be put into a standard. I point out >some of those sections as I went through. >[page 10] > Object descriptors (the "human readable names" assigned to object >identifiers [5]) defined in standard MIB modules should be unique across >all MIB modules. > >Not sure that this is possible, desirable, or required. I think that being >unique within a MIB module is just fine. Besides, vendors MIBs will likely >use a name that is being used by some other module. The experts I spoke with have said this isn't good to do. Also I know of one implementation (hp openview xnmloadmib) where such things will cause import errors. Granted enterprise mib modules may have overlaps, so the problem remains. sming should fix this. >[page 10] > Secondly, management > applications can be pointed at specific subtrees for fault or >configuration, causing a more efficient retrieval of data and a simpler >management application with potentially better performance. > >I don't get this point which is in the section called "Naming MIB Modules >and Managed Objects". How does naming objects have anything to do with the >OID tree structure? I'll take a stab at this, though Jon or Wayne should chime in. Many folks assume there is a relationship between the names and the branches of the oid tree. The example above goes into one specific approach to grouping information with a given name. Would it be useful to have a real example? >[page 27] > An example of such an object from the OSPF Version 2 MIB [27] is the > global ospfAdminStat: > > ospfAdminStat OBJECT-TYPE > SYNTAX Status > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The administrative status of OSPF in the > router. The value 'enabled' denotes that the > OSPF Process is active on at least one inter- > face; 'disabled' disables it on all inter- > faces." > ::= { ospfGeneralGroup 2 } > >This object does not seem to match the discussion from the previous >paragraphs. The point that I get from the section is that you are describing >how to activate parts of a configuration. It seems that this object is >activating a process which uses some configuration. I thought that you would >present an object that controls some part of the configuration. I see your point, the above object does activate the whole config and not a part of it. I will find a better example from a standard mib module. >---- > >[page 32] > INFORM PDUs, as opposed to TRAP PDUs, have an inherent advantage >when > the concern is the reduction of unneccessary messages from the >system > generating the NOTIFICATION-TYPE data. > >I don't understand what the inherent advantage is. This statement could use >some clarification. Jon, can you augment paragraph 3 of 3.10.2 ? In the code I've seen, you have two cases: 1) a given event occurs either slower than can be delivered to manager station or faster. In the slow case, there isn't anything "reduction" as the agent didn't care and the manager which may or may not have seen the event eventually polled for status and took care of the problem anyway. 2) In the fast case, an inform will just cause a backup of messages in the agent, and some events will be dumped (queue full) before being sent. I guess this is a "reduction" of traffic on the wire :-) From owner-snmpconf@seymour39.SNMP.COM Sat Jan 12 09:29:21 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20747 for ; Sat, 12 Jan 2002 09:29:20 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA21562 for snmpconf-outgoing; Sat, 12 Jan 2002 09:19:53 -0500 (EST) Message-Id: <200201121417.JAA08551@europa-h0001027441c5.ne.mediaone.net> Content-Type: text/plain; charset="iso-8859-1" From: "Jon Saperia " Organization: JDS Consulting, Inc. To: snmpconf@snmp.com, Michael MacFaden Subject: Re: Review of draft-ietf-snmpconf-bcp-07 Date: Sat, 12 Jan 2002 09:17:56 -0500 X-Mailer: KMail [version 1.3.2] References: <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <20020111175900.K1364@riverstonenet.com> In-Reply-To: <20020111175900.K1364@riverstonenet.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit On Friday 11 January 2002 08:59 pm, Michael MacFaden wrote: > Glen, > > Thanks very much for the detailed review as well as the > impression the document left you with. > > Below are some comments... > > Regards, > Mike > Glen, thanks also for your comments. This also gives me a chance to say where we are on revisions to the document. We have recieved comments on the most recent version for Bert in a handwritten form, David Partain, and Rand P who posted to this list some time ago. We are happy to work on your comments as well. I do have some comments on them and rather than starting multiple threads, I have replied to the comments Mike made. We did spend quit a lot of time on Thursday going over the handwritten notes that Bert provided. Some were specific and detailed, others were not. David Partain was also very thorough and even gave us a diff. Our goal is to work through these over the next week or so. Not to the comeents on the comments. > On Fri, Jan 11, 2002 at 08:11:58PM -0500, Glenn Waters wrote: > >First, I have a hard time with the classification of this document as a > > BCP. There is some BCP content but there is also content that is > > Experimental, Informational, and, some which should be put into a > > standard. I point out some of those sections as I went through. > > We have discussed this point in the past at some length. This is a hard call here, but at some point in the future if more work is done in this area and we need standardization, that can happen. I still feel BCP is the best general description. With regard to your comments about configuraiton with SNMP. Yes, it does add complexity but in my experience now with at least 4 implementations of systems that use SNMP as a configuration method, it is just not as hard as many people that have not done it indicate. These implementations include products that range from shipping bandwidth management products in quite small footprints to very large router types of products. Much of the work is in the design of the MIB Objects. Done following some of the principles in the BCP, it makes the task easier and the resulting product more useful at least for those of us that wish to write sophisticated management applications. This is really not too relevant to the BCP at this point except to say that people can and do build products successfully this way. > >[page 10] > > Object descriptors (the "human readable names" assigned to object > >identifiers [5]) defined in standard MIB modules should be unique > > across all MIB modules. > > > >Not sure that this is possible, desirable, or required. I think that > > being unique within a MIB module is just fine. Besides, vendors MIBs > > will likely use a name that is being used by some other module. > > The experts I spoke with have said this isn't good to do. > Also I know of one implementation (hp openview xnmloadmib) where such > things will cause import errors. > > Granted enterprise mib modules may have overlaps, so the problem > remains. sming should fix this. Mike, is quite correct in my experience with applications. His example of HP is one. I had a similar experience with the SUN product not that long ago. > > >[page 10] > > Secondly, management > > applications can be pointed at specific subtrees for fault or > >configuration, causing a more efficient retrieval of data and a simpler > >management application with potentially better performance. > > > >I don't get this point which is in the section called "Naming MIB > > Modules and Managed Objects". How does naming objects have anything to > > do with the OID tree structure? > > I'll take a stab at this, though Jon or Wayne should chime in. > > Many folks assume there is a relationship between the names and the > branches of the oid tree. The example above goes into one specific > approach to grouping information with a given name. Would it be useful > to have a real example? Glen/Mike When constructing a management application to work with an agent, if the counters for a particular part of the sub system fall withing a single branch like the acmeFooStatistics group, then with a single OID, I can tell the system to retrieve all the data needed to know about Foo statistics without having to put into the manager several OIDs. It is just good organization of data. > > >[page 27] > > An example of such an object from the OSPF Version 2 MIB [27] is the > > global ospfAdminStat: > > > > ospfAdminStat OBJECT-TYPE > > SYNTAX Status > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The administrative status of OSPF in the > > router. The value 'enabled' denotes that the > > OSPF Process is active on at least one inter- > > face; 'disabled' disables it on all inter- > > faces." > > > > ::= { ospfGeneralGroup 2 } > > > >This object does not seem to match the discussion from the previous > >paragraphs. The point that I get from the section is that you are > > describing how to activate parts of a configuration. It seems that > > this object is activating a process which uses some configuration. I > > thought that you would present an object that controls some part of > > the configuration. > > I see your point, the above object does activate the whole config > and not a part of it. I will find a better example from a standard mib > module. > Mike please pass that on to use and we will be sure to include it. > >---- > > > >[page 32] > > INFORM PDUs, as opposed to TRAP PDUs, have an inherent advantage > >when > > the concern is the reduction of unneccessary messages from the > >system > > generating the NOTIFICATION-TYPE data. > > > >I don't understand what the inherent advantage is. This statement could > > use some clarification. > > Jon, can you augment paragraph 3 of 3.10.2 ? Yup, you folks are quite correct. Wayne and I talked about this the other day. We have some new words. > > In the code I've seen, you have two cases: > 1) a given event occurs either slower than can be delivered > to manager station or faster. > In the slow case, there isn't anything "reduction" > as the agent didn't care and the manager which may > or may not have seen the event eventually polled for > status and took care of the problem anyway. > > 2) In the fast case, an inform will just cause a backup > of messages in the agent, and some events will be dumped > (queue full) before being sent. I guess this is a > "reduction" of traffic on the wire :-) -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-snmpconf@seymour39.SNMP.COM Sat Jan 12 09:57:29 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20915 for ; Sat, 12 Jan 2002 09:57:28 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id JAA21624 for snmpconf-outgoing; Sat, 12 Jan 2002 09:49:32 -0500 (EST) Message-Id: <200201121447.JAA08789@europa-h0001027441c5.ne.mediaone.net> Content-Type: text/plain; charset="iso-8859-1" From: "Jon Saperia " Organization: JDS Consulting, Inc. To: snmpconf@snmp.com, "Glenn Waters" Subject: Re: Review of draft-ietf-snmpconf-bcp-07 --Additional Comment Date: Sat, 12 Jan 2002 09:47:54 -0500 X-Mailer: KMail [version 1.3.2] References: <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit On Friday 11 January 2002 08:11 pm, Glenn Waters wrote: > Second, there are some sections of the document that seem to gloss over > the detail. Sections 4 and 5 are notable examples where the concepts are > hastily presented and conclusions on how to deal with the issue is light > on detail. I found reviewing these sections very difficult since if I > were to write anything then I would have to spend a huge amount of time > giving the feedback. I do note that the topics in those sections are > very complexity and I can understand why I feel that they are light. I > am not sure how or if they should fit into this document. Mike did not comment on this so it was not in my previous reply. The approach that we took is that an increment in information is better than the current lack in some of these areas, particularly with regard to management applications (section 5). I have to agree with your observation that quite a lot more could be written. We think the observations contained in these sections while not complete add to understanding and are good practices. Section 5 stems mostly from my experience sometimes learned the hard way. /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 09:22:10 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02937 for ; Mon, 14 Jan 2002 09:22:10 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA26817 for snmpconf-outgoing; Mon, 14 Jan 2002 09:07:51 -0500 (EST) Message-Id: <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jan 2002 09:06:13 -0500 To: snmpconf@snmp.com From: John Schnizlein Subject: Re: Review of draft-ietf-snmpconf-bcp-07 In-Reply-To: <200201121417.JAA08551@europa-h0001027441c5.ne.mediaone.net > References: <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <20020111175900.K1364@riverstonenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Questioning the appropriateness of describing configuration through SNMP as Best Current Practice will not go away. The most basic reason for this is that it is not a current practice. Among the interesting observations discussed in the Configuration BOF (Salt Lake City 12/10) was Randy' Bush's summary: "We can't find anybody using SNMP to configure." What are the "at least 4 implementations of systems that use SNMP as a configuration method" mentioned in your reply below? Maybe we missed them. John At 09:17 AM 1/12/2002, Jon Saperia wrote: >On Friday 11 January 2002 08:59 pm, Michael MacFaden wrote: >> On Fri, Jan 11, 2002 at 08:11:58PM -0500, Glenn Waters wrote: >> >First, I have a hard time with the classification of this document as a >> > BCP. There is some BCP content but there is also content that is >> > Experimental, Informational, and, some which should be put into a >> > standard. I point out some of those sections as I went through. >> > >We have discussed this point in the past at some length. This is a hard >call here, but at some point in the future if more work is done in this >area and we need standardization, that can happen. I still feel BCP is the >best general description. > >With regard to your comments about configuraiton with SNMP. Yes, it does >add complexity but in my experience now with at least 4 implementations of >systems that use SNMP as a configuration method, it is just not as hard as >many people that have not done it indicate. These implementations include >products that range from shipping bandwidth management products in quite >small footprints to very large router types of products. Much of the work >is in the design of the MIB Objects. Done following some of the principles >in the BCP, it makes the task easier and the resulting product more useful >at least for those of us that wish to write sophisticated management >applications. This is really not too relevant to the BCP at this point >except to say that people can and do build products successfully this way. From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 12:14:42 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07594 for ; Mon, 14 Jan 2002 12:14:42 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA01100 for snmpconf-outgoing; Mon, 14 Jan 2002 12:03:33 -0500 (EST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John Schnizlein Cc: snmpconf@snmp.com Subject: Re: Review of draft-ietf-snmpconf-bcp-07 References: <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> Message-Id: Date: Mon, 14 Jan 2002 09:02:53 -0800 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > "We can't find anybody using SNMP to configure." and many vendors, including prominent ones, don't even implement writing of all the things which would be needed. > What are the "at least 4 implementations of systems that use SNMP as > a configuration method" mentioned in your reply below? as the 'p' in bcp stands for 'practice,' who are the USERS who use snmp as their configuration method? randy From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 13:33:37 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11461 for ; Mon, 14 Jan 2002 13:33:37 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA02236 for snmpconf-outgoing; Mon, 14 Jan 2002 13:22:02 -0500 (EST) Message-Id: <5.0.2.1.2.20020114095344.02873040@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 14 Jan 2002 10:21:06 -0800 To: snmpconf@snmp.com From: "David T. Perkins" Subject: Re: Review of draft-ietf-snmpconf-bcp-07 In-Reply-To: References: <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com HI, There are specific products and markets where configuration is done via SNMP. For example, the interoperable way to configure RMON probes, and cable modems across device vendors is to use SNMP. There way also be other examples in specific areas. Let me go out on a limb here... Where there is a standard way to perform configuration that works across products from different vendors, SNMP is probably the mechanism that is being used. Creating a standard approach is more time consuming and expensive for early device vendors (than creating proprietary mechanisms). (And it can be much cheaper for follow-on device vendors). Creating multiple standards (one for each technology area) for use in a modern router (where there is some amount of interaction) is a quite difficult problem. For example, configuration of brand C routers is based on creating access control lists (ACLs), which are used as a selection mechanism in configuration of many different technologies. Brand X router, may use a different model for a selection mechanism. How is a set of configuration standards created that has dependencies between standards and can be implemented by different device vendors? Moving even farther out on the limb... It doesn't seem to me that it is the SNMP protocol, or SNMP's SMI, but an immaturity and/or diversity of configuration models found in modern routers from different device vendors. Creating another protocol or data modeling language will probably not help. If this is the case, then the area needs some really smart, experienced, and motivated people with a shared goal to make some progress. I'll be the first to support them. But I'm also leery of sales agents of simple solutions or those that make unsupported claims. At 09:02 AM 1/14/2002 -0800, Randy Bush wrote: >> "We can't find anybody using SNMP to configure." > >and many vendors, including prominent ones, don't even implement writing of >all the things which would be needed. > >> What are the "at least 4 implementations of systems that use SNMP as >> a configuration method" mentioned in your reply below? > >as the 'p' in bcp stands for 'practice,' who are the USERS who use snmp as >their configuration method? > >randy Regards, /david t. perkins From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 14:15:38 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13741 for ; Mon, 14 Jan 2002 14:15:38 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA03000 for snmpconf-outgoing; Mon, 14 Jan 2002 14:05:54 -0500 (EST) Date: Mon, 14 Jan 2002 11:05:17 -0800 From: Michael MacFaden To: snmpconf@snmp.com Subject: Re: Fwd: Re: Review of draft-ietf-snmpconf-bcp-07 Message-ID: <20020114110517.A991@riverstonenet.com> References: <200201141542.KAA09992@europa-h0001027441c5.ne.mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201141542.KAA09992@europa-h0001027441c5.ne.mediaone.net>; from saperia@jdscons.com on Mon, Jan 14, 2002 at 10:42:09AM -0500 X-Operating-System: GNU/Linux 2.4.17 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >Subject: Re: Review of draft-ietf-snmpconf-bcp-07 >Date: Mon, 14 Jan 2002 09:06:13 -0500 >From: John Schnizlein >To: snmpconf@snmp.com > >Questioning the appropriateness of describing configuration through >SNMP as Best Current Practice will not go away. The most basic reason >for this is that it is not a current practice. If you've been dealing only on core/distribution router networks and the gear that serve that market I'd agree. However, the reality is that snmp is used for configuration at the access/edge of service provider and enterprise networks. >What are the "at least 4 implementations of systems that use SNMP as >a configuration method" mentioned in your reply below? >Maybe we missed them. Indeed. I can give you four different types of devices that configure primarily through SNMP. 1) All DOCSIS cable modem systems are configured using SNMP directly or using it to control tftp download of config. Cable Modem manufactuerers: http://www.cable-modems.org/gallery/ CMTS systems including those built by ciscoSystems, must have a complete set of standard read-write objects which are lightly verified. 2) All ATM Switches. Customers like IXC, RBOC, PTT use SNMP to configure most every ATM switch I know of (Fore, Lucent, and even stratacom at one point a while back). Problem here was that they all use private MIB modules and not the ones defined in ATM/ATM2 MIBs so no standard applications can be written much less sustain a software company. 3) Every IEEE transparent bridge w/mgmt support. hp, 3com, cisco, extreme, foundry, riverstone, etc. IEEE continues to get it right compared IETF protocols in terms of defining in the base protocol the set of common management operations one might need. More than one greenfield service provider (esp metro ones) have built mgmt systems that can control 1493, 2674 compliant networks. Has the same problem as #2 but as severe. Lack of testing does make some concerns about implementation and proprietary mib objects are still needed to do things standards refuses to support but all vendors gear has. (like: turn off stp on a per port basis). 4) Many sundry devices have SNMP support. Just pick up a current copy of Network Computing and look at the advertisements: a) UPS systems (American Power Conversion, others) b) Intelligent Power strips (can't remember the name) c) Environmental monitors (netbotz) d) Apple Airport (completely not standard use of SNMP though) Thus SNMP is used for configuration if: 1) Customers are willing to pay the higher cost (relative to a proprietary cli) to build it and get as many bugs out of the implementation as the customer needs. (What Andy Bierman keeps reminding everyone) 2) It is a market requirement such that vendors have it forced down their throat as the DOCSIS organization does. 3) Your base protocol/device had the management plane sufficiently thought through in the first place. If the thing one is configuring is relatively simple and doesn't cause reachablity problems in the rest of the Internet if you misconfigure it, then the implementation bugs that might be in an SNMP implementation don't hide the underlying bugs in the protocol/device. (what I call shooting the messenger or simply a complexity tradeoff). Mike MacFaden www.nmops.org www.riverstonenet.com From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 14:24:36 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14311 for ; Mon, 14 Jan 2002 14:24:36 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA03119 for snmpconf-outgoing; Mon, 14 Jan 2002 14:16:51 -0500 (EST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael MacFaden Cc: snmpconf@snmp.com Subject: Re: Fwd: Re: Review of draft-ietf-snmpconf-bcp-07 References: <200201141542.KAA09992@europa-h0001027441c5.ne.mediaone.net> <20020114110517.A991@riverstonenet.com> Message-Id: Date: Mon, 14 Jan 2002 11:16:16 -0800 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit >> Questioning the appropriateness of describing configuration through >> SNMP as Best Current Practice will not go away. The most basic reason >> for this is that it is not a current practice. > If you've been dealing only on core/distribution router networks and the > gear that serve that market I'd agree. However, the reality is that snmp > is used for configuration at the access/edge of service provider and > enterprise networks. by whom? despite a year of looking, going to meetings on four continents, talking to enterprises and isps, ... we have not found this to be the case. as cisco and other do not even implement config via snmp, such broad statements do not see very supportable. yes, various edge devices do config via snmp. and if that is the only means they provide, that's what folk are forced to use. but you will find that, if they have a choice, they use cli, whether we like it or not. for what happens in the market, remember cascade. randy From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 15:01:28 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16191 for ; Mon, 14 Jan 2002 15:01:28 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id OAA03872 for snmpconf-outgoing; Mon, 14 Jan 2002 14:52:57 -0500 (EST) Message-Id: <4.3.2.7.2.20020114134101.037d6d60@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jan 2002 14:43:59 -0500 To: snmpconf@snmp.com From: John Schnizlein Subject: Re: Review of draft-ietf-snmpconf-bcp-07 In-Reply-To: <5.0.2.1.2.20020114095344.02873040@mail4.bayarea.net> References: <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 01:21 PM 1/14/2002, David T. Perkins wrote: >There are specific products and markets where configuration is done >via SNMP. For example, the interoperable way to configure RMON probes, >and cable modems across device vendors is to use SNMP. I don't claim to be an expert on cable modems. My understanding is that the usual operation of cable modems is as specified by DOCSIS. Admiting that I don't have the most current documentation, the August 29, 2001 Operations Support System Interface Specification (SP-OSSIv1.1-I04-010829) contains this on page 30: During initialization, a CM communicates with a DHCP Server that provides the CM with its assigned IP address and, in addition, provides a pointer to the TFTP Server that stores the assigned CM Config File for that CM. The CM reads the CM Config File and forwards the set of Service Flow definitions (using SCNs) up to the CMTS... My interpretation (maybe there is a clearer quote) is that DOCSIS configuration is performed through Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol, not SNMP. This document specifies in detail how SNMP is configured along with other things through these protocols. So, cable modems are an example where SNMP is NOT used in practice for configuration. I know even less about RMON probes, but since RMON is a creature of SNMP, its configuration through SNMP would constitute configuring SNMP features through SNMP, not configuring the network through SNMP. >... >If this is the case, then the area needs some really smart, >experienced, and motivated people with a shared goal to make >some progress. I'll be the first to support them. But I'm also >leery of sales agents of simple solutions or those that make >unsupported claims. We agree on the need for smart people with shared goals to invent configuration solutions for networks. Randy is trying to gather and organize the perspective of operators in a fresh start on this effort. My impression is that there is not a Current Best Practice for network configuration to be documented. Instead, there are lots of creative ideas. Don't know who you see as a sales agent. I am not making unsupported claims, just asking for actual instances of the practice of configuring through SNMP. John From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 15:05:04 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16396 for ; Mon, 14 Jan 2002 15:05:03 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA04030 for snmpconf-outgoing; Mon, 14 Jan 2002 14:57:03 -0500 (EST) Date: Mon, 14 Jan 2002 11:56:19 -0800 From: Michael MacFaden To: Randy Bush Cc: snmpconf@snmp.com Subject: Re: Fwd: Re: Review of draft-ietf-snmpconf-bcp-07 Message-ID: <20020114115619.B991@riverstonenet.com> References: <200201141542.KAA09992@europa-h0001027441c5.ne.mediaone.net> <20020114110517.A991@riverstonenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com on Mon, Jan 14, 2002 at 11:16:16AM -0800 X-Operating-System: GNU/Linux 2.4.17 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com On Mon, Jan 14, 2002 at 11:16:16AM -0800, Randy Bush wrote: >>> Questioning the appropriateness of describing configuration through >>> SNMP as Best Current Practice will not go away. The most basic reason >>> for this is that it is not a current practice. >> If you've been dealing only on core/distribution router networks and the >> gear that serve that market I'd agree. However, the reality is that snmp >> is used for configuration at the access/edge of service provider and >> enterprise networks. > >by whom? despite a year of looking, going to meetings on four continents, >talking to enterprises and isps, ... we have not found this to be the case. If you conducted an actual study in a scientific manner, I'd like to see the data before the conclusion. The list above does not include the specific customers I mentioned: telcos (the atm part, not the isp part), cable modem, layer 1/2 metro serivce providers. Go ask these folks what gear they use and how the manage it. >as cisco and other do not even implement config via snmp, such broad >statements do not see very supportable. Cisco *does* support snmp config where there is a market requirement or is legacy gear that already supports it as in the case of the uBR (see Azlina Palmer) or the Catalyst 3k(kalpana)/5k(creshendo) transparent bridge product lines (Cal Palmore). >if they have a choice, they use cli, whether we like it or not. I sympathise with your zeal for a smaller simpler to use/create management interface. Really I do. If customers have a choice of mgmt interfaces, they will prefer/use any number of interfaces. Over the years I've been asked to support in addition to SNMP: HTTP, JavaBeans, TL1, XML, COPS, LDAP, a GUI craft interface and configuration through an EMS. I then explain the benefits of our product's CLI, such as cmds are placed into scrachpad and activated at once, difference between a active ram configuration and bootup configuration, joys of editing acls with an online editor, being able to diff and search configs while in config mode, authentication with raduius/tacacs+, etc. Truth be told, Customers will use whatever they understand and whatever doesn't crash or impede the device. Mike MacFaden From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 15:19:33 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17197 for ; Mon, 14 Jan 2002 15:19:33 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA04392 for snmpconf-outgoing; Mon, 14 Jan 2002 15:10:08 -0500 (EST) Date: Mon, 14 Jan 2002 12:09:34 -0800 From: Michael MacFaden To: snmpconf@snmp.com Subject: Re: Review of draft-ietf-snmpconf-bcp-07 Message-ID: <20020114120934.D991@riverstonenet.com> References: <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> <5.0.2.1.2.20020114095344.02873040@mail4.bayarea.net> <4.3.2.7.2.20020114134101.037d6d60@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20020114134101.037d6d60@diablo.cisco.com>; from jschnizl@cisco.com on Mon, Jan 14, 2002 at 02:43:59PM -0500 X-Operating-System: GNU/Linux 2.4.17 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com On Mon, Jan 14, 2002 at 02:43:59PM -0500, John Schnizlein wrote: >At 01:21 PM 1/14/2002, David T. Perkins wrote: > >>There are specific products and markets where configuration is done >>via SNMP. For example, the interoperable way to configure RMON probes, >>and cable modems across device vendors is to use SNMP. > >I don't claim to be an expert on cable modems. My understanding is >that the usual operation of cable modems is as specified by DOCSIS. >Admiting that I don't have the most current documentation, the >August 29, 2001 Operations Support System Interface Specification >(SP-OSSIv1.1-I04-010829) contains this on page 30: > > During initialization, a CM communicates with a DHCP Server that > provides the CM with its assigned IP address and, in addition, > provides a pointer to the TFTP Server that stores the assigned > CM Config File for that CM. The CM reads the CM Config File and > forwards the set of Service Flow definitions (using SCNs) up to > the CMTS... John, Please keep reading. SNMP is an application layer protocol so SNMP can't do any initial device configuration. Once a cable modem is up and running cable modems and cable modem head ends are managed via SNMP to tweak and endless number of configuration bits. See RFC 2669, 2670 or give Rich Woundy at Cisco a call. Most all other devices I listed behave the same way. The low end devices often come with a preconfigure ip address: Gee, what should it be? Hmm. Underlying hacks must then be invented to figure out how to make such things simpler. Regards, Mike From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 15:20:50 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17252 for ; Mon, 14 Jan 2002 15:20:49 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA04430 for snmpconf-outgoing; Mon, 14 Jan 2002 15:11:49 -0500 (EST) Message-Id: <200201142009.PAA10240@europa-h0001027441c5.ne.mediaone.net> Content-Type: text/plain; charset="iso-8859-1" From: "Jon Saperia " Organization: JDS Consulting, Inc. To: snmpconf@snmp.com, Randy Bush , Michael MacFaden Subject: Re: Fwd: Re: Review of draft-ietf-snmpconf-bcp-07 Date: Mon, 14 Jan 2002 15:09:53 -0500 X-Mailer: KMail [version 1.3.2] Cc: snmpconf@snmp.com References: <200201141542.KAA09992@europa-h0001027441c5.ne.mediaone.net> <20020114110517.A991@riverstonenet.com> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit On Monday 14 January 2002 02:16 pm, Randy Bush wrote: > by whom?  despite a year of looking, going to meetings on four > continents, talking to enterprises and isps, ... we have not found this > to be the case. I would like to add to Mikes comments since he started to 'name names'. There is of course the RMON set of vendors that include Netscout. There are other vendors in this market as well such as HP et. al.. I mention Netscout since I have built applications that configure it (and other probes) and use the resulting data for network performance analysis. The application also configured other RMON devices from other vendors as well. Certainly RMON is a widely deployed and used technology. A different type of product than RMON or the switch/router vendors are the bandwidth manger products. One such example is Sitara Networks. Their entire policy for Qos can be provisioned through a number of techniques including SNMP. In fact, they have an application called the QosDirector that was a best of show finalist and peoples choice award winner not too long ago. This product has been shipping for some time as well though RMON is clearly the oldest in this category. In terms of router types of products, IronBridge Networks provided a standard CLI that would be familiar to most people that was based on an SNMP infrastructure. It's performance was reasonably comparable to CLI only based systems that are the norm in most core environments. One of the reasons that you may not have heard about the examples Mike put forward or these is that like network operators, many of the people who are building products for a living to not spend time on IETF lists of any kind. They are busy building product. With regard to the points about whether this should be a BCP or not we have indeed discussed this. In section 5 of RFC2026, I see nothing that raises the bar of such documents to include deployment or use. That said, The examples I provided above along with Mikes indicate not only deployment but actual use. /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 15:23:48 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17366 for ; Mon, 14 Jan 2002 15:23:47 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA04487 for snmpconf-outgoing; Mon, 14 Jan 2002 15:15:03 -0500 (EST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael MacFaden Cc: snmpconf@snmp.com Subject: Re: Review of draft-ietf-snmpconf-bcp-07 References: <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> <5.0.2.1.2.20020114095344.02873040@mail4.bayarea.net> <4.3.2.7.2.20020114134101.037d6d60@diablo.cisco.com> <20020114120934.D991@riverstonenet.com> Message-Id: Date: Mon, 14 Jan 2002 12:14:30 -0800 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > SNMP is an application layer protocol > so SNMP can't do any initial device configuration. > Once a cable modem is up and running cable modems and cable modem head > ends are managed via SNMP to tweak and endless number of > configuration bits. See RFC 2669, 2670 or give Rich Woundy > at Cisco a call. when you have to scale, tweaking single devices is just not on. the canonic configuration is on a disk drive. randy From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 15:54:02 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18613 for ; Mon, 14 Jan 2002 15:54:02 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA05194 for snmpconf-outgoing; Mon, 14 Jan 2002 15:44:27 -0500 (EST) Date: Mon, 14 Jan 2002 12:43:50 -0800 From: Michael MacFaden To: Randy Bush Cc: snmpconf@snmp.com Subject: Re: Review of draft-ietf-snmpconf-bcp-07 Message-ID: <20020114124350.G991@riverstonenet.com> References: <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> <5.0.2.1.2.20020114095344.02873040@mail4.bayarea.net> <4.3.2.7.2.20020114134101.037d6d60@diablo.cisco.com> <20020114120934.D991@riverstonenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com on Mon, Jan 14, 2002 at 12:14:30PM -0800 X-Operating-System: GNU/Linux 2.4.17 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com On Mon, Jan 14, 2002 at 12:14:30PM -0800, Randy Bush wrote: >> SNMP is an application layer protocol >> so SNMP can't do any initial device configuration. >> Once a cable modem is up and running cable modems and cable modem head >> ends are managed via SNMP to tweak and endless number of >> configuration bits. See RFC 2669, 2670 or give Rich Woundy >> at Cisco a call. > >when you have to scale, tweaking single devices is just not on. the >canonic configuration is on a disk drive. My words above may give the wrong impression of how things work, sorry. If you spend time in the operations of a cable modem shop, I haven't heard of many scaling issues other than managing nasty coax/how many upstreams you can get&need 1x4/7/... Mike St John and crew figured out the scaling issues pretty well. At the time of @Home's demise, over 5 milllion subscribers were being served across a number of continents, across a number of mom and pop HFC networks (the kind that reboots your head ends when their m$ dhcp server doesn't work). That's an alot of devices that support full read-write SNMP configuration in RFC 2670 plus the updated MIB-II objects 1907/2863/2011-13/2096. They got config, diag, and monitoring stuff nicely wrapped up in one consistent protocol (albeit SNMP) and then the market muscle (docsis org) to make vendors to implement it consistently. Could it have been done with a standard CLI? Absolutely. Thanks, Mike From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 15:58:10 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18765 for ; Mon, 14 Jan 2002 15:58:09 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA05262 for snmpconf-outgoing; Mon, 14 Jan 2002 15:49:34 -0500 (EST) Message-Id: <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jan 2002 15:47:55 -0500 To: snmpconf@snmp.com From: John Schnizlein Subject: Re: Review of draft-ietf-snmpconf-bcp-07 In-Reply-To: References: <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> <5.0.2.1.2.20020114095344.02873040@mail4.bayarea.net> <4.3.2.7.2.20020114134101.037d6d60@diablo.cisco.com> <20020114120934.D991@riverstonenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I hope "to tweak endless number of configuration bits" is not being put forward as best practice for network configuration. The existence of a (small fraction) of R/W MIB variables is not a very compelling argument for the "best practice" claim. Can you name the operator of a network who would say that they configure their network through SNMP? This is different from using SNMP for monitoring and tweaking. John At 03:14 PM 1/14/2002, Randy Bush wrote: >> SNMP is an application layer protocol >> so SNMP can't do any initial device configuration. >> Once a cable modem is up and running cable modems and cable modem >> head ends are managed via SNMP to tweak and endless number of >> configuration bits. > >when you have to scale, tweaking single devices is just not on. >the canonic configuration is on a disk drive. > >randy From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 16:08:09 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19276 for ; Mon, 14 Jan 2002 16:08:08 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA05390 for snmpconf-outgoing; Mon, 14 Jan 2002 15:58:52 -0500 (EST) Message-ID: <0BF8B32B723ED5119E0B0002A551748B01FA07A3@corp-exc3.ctron.com> From: "Harrington, David" To: "'snmpconf@snmp.com'" Subject: RE: Review of draft-ietf-snmpconf-bcp-07 Date: Mon, 14 Jan 2002 15:56:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19D3D.F66AE110" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19D3D.F66AE110 Content-Type: text/plain > when you have to scale, tweaking single devices is just not on. Which is where using an application helps to automate and coordinate the process. CLI scripting is one way to automate the process, but SNMP applications are much more able to respond to a wide variety of differences or changes in the environment, and apply appropriately adjusted configurations to multiple devices. dbh > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, January 14, 2002 3:15 PM > To: MacFaden, Mike > Cc: snmpconf@snmp.com > Subject: Re: Review of draft-ietf-snmpconf-bcp-07 > > > > SNMP is an application layer protocol > > so SNMP can't do any initial device configuration. > > Once a cable modem is up and running cable modems and cable > modem head > > ends are managed via SNMP to tweak and endless number of > > configuration bits. See RFC 2669, 2670 or give Rich Woundy > > at Cisco a call. > > when you have to scale, tweaking single devices is just not on. the > canonic configuration is on a disk drive. > > randy > ------_=_NextPart_001_01C19D3D.F66AE110 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Review of draft-ietf-snmpconf-bcp-07

> when you have to scale, tweaking single devices = is just not on.

Which is where using an application helps to automate = and coordinate the process. CLI scripting is one way to automate the = process, but SNMP applications are much more able to respond to a wide = variety of differences or changes in the environment, and apply = appropriately adjusted configurations to multiple devices.

dbh

> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Monday, January 14, 2002 3:15 PM
> To: MacFaden, Mike
> Cc: snmpconf@snmp.com
> Subject: Re: Review of = draft-ietf-snmpconf-bcp-07
>
>
> > SNMP is an application layer = protocol
> > so SNMP can't do any initial device = configuration.
> > Once a cable modem is up and running cable = modems and cable
> modem head
> > ends are managed via SNMP to tweak and = endless number of
> > configuration bits. See RFC 2669, 2670 or = give Rich Woundy
> > at Cisco a call.
>
> when you have to scale, tweaking single devices = is just not on.  the
> canonic configuration is on a disk = drive.
>
> randy
>

------_=_NextPart_001_01C19D3D.F66AE110-- From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 16:09:53 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19359 for ; Mon, 14 Jan 2002 16:09:52 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA05498 for snmpconf-outgoing; Mon, 14 Jan 2002 16:01:51 -0500 (EST) Message-Id: <200201142100.QAA10422@europa-h0001027441c5.ne.mediaone.net> Content-Type: text/plain; charset="iso-8859-1" From: "Jon Saperia " Organization: JDS Consulting, Inc. To: snmpconf@snmp.com, John Schnizlein Subject: Re: Review of draft-ietf-snmpconf-bcp-07 Date: Mon, 14 Jan 2002 16:00:14 -0500 X-Mailer: KMail [version 1.3.2] References: <20020114120934.D991@riverstonenet.com> <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> In-Reply-To: <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit On Monday 14 January 2002 03:47 pm, John Schnizlein wrote: > I hope "to tweak endless number of configuration bits" is not > being put forward as best practice for network configuration. The Best Current Practices document we have written has a focus on SNMP, thus the title Configuring Networks and Devices With SNMP. It does not claim to be the final best approach for configuration of networks. I think we are a long way from there. It does offer good approaches for configuration when one uses SNMP. > > The existence of a (small fraction) of R/W MIB variables is not a very > compelling argument for the "best practice" claim. Can you name the > operator of a network who would say that they configure their network > through SNMP? > I have provided examples of products that have SNMP configurability for their major operational compoents, are shipping and in use. /jon > This is different from using SNMP for monitoring and tweaking. > > John > > At 03:14 PM 1/14/2002, Randy Bush wrote: > >> SNMP is an application layer protocol > >> so SNMP can't do any initial device configuration. > >> Once a cable modem is up and running cable modems and cable modem > >> head ends are managed via SNMP to tweak and endless number of > >> configuration bits. > > > >when you have to scale, tweaking single devices is just not on. > >the canonic configuration is on a disk drive. > > > >randy -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 16:26:55 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20155 for ; Mon, 14 Jan 2002 16:26:54 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA05783 for snmpconf-outgoing; Mon, 14 Jan 2002 16:18:27 -0500 (EST) Date: Mon, 14 Jan 2002 13:17:53 -0800 From: Michael MacFaden To: snmpconf@snmp.com Subject: Re: Review of draft-ietf-snmpconf-bcp-07 Message-ID: <20020114131753.B1324@riverstonenet.com> References: <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> <5.0.2.1.2.20020114095344.02873040@mail4.bayarea.net> <4.3.2.7.2.20020114134101.037d6d60@diablo.cisco.com> <20020114120934.D991@riverstonenet.com> <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com>; from jschnizl@cisco.com on Mon, Jan 14, 2002 at 03:47:55PM -0500 X-Operating-System: GNU/Linux 2.4.17 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com On Mon, Jan 14, 2002 at 03:47:55PM -0500, John Schnizlein wrote: >I hope "to tweak endless number of configuration bits" is not >being put forward as best practice for network configuration. No more so than tweaking metrics on routing protocols or updating access control lists or handling connectivity problems due to an implementation bug when an edge router sees invalid cruft from another edge router whose software was just updated. You just have admire this quote from Tony Li: Be liberal in what you accept, conservative in what you send, and add a knob so that you can interoperate even if the other guy blows it. That kind of tweaking...of course it isn't a BCP. >The existence of a (small fraction) of R/W MIB variables is not a very >compelling argument for the "best practice" claim. Can you name the >operator of a network who would say that they configure their network >through SNMP? Strangely, they may or may not know they use SNMP. Customers will to me things like, I use Lucent NavisCore or some other marketing term for an EMS product and that is how they want to configure their network. If you define/use SNMP read-write objects and implement the Internet Standard Management Framework, the BCP attempts to show how things have progressed in the past ten years or so and what works and what to watch out for and to some extent, what the current 'thinking' is. Mike From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 16:30:14 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20290 for ; Mon, 14 Jan 2002 16:30:14 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA05828 for snmpconf-outgoing; Mon, 14 Jan 2002 16:21:34 -0500 (EST) Message-Id: <4.3.2.7.2.20020114160749.0383f008@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jan 2002 16:17:57 -0500 To: saperia@jdscons.com From: John Schnizlein Subject: Re: Review of draft-ietf-snmpconf-bcp-07 Cc: snmpconf@snmp.com In-Reply-To: <200201142100.QAA10422@europa-h0001027441c5.ne.mediaone.net > References: <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> <20020114120934.D991@riverstonenet.com> <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 04:00 PM 1/14/2002, Jon Saperia wrote: >On Monday 14 January 2002 03:47 pm, John Schnizlein wrote: >> >> Can you name the operator of a network who would say that >> they configure their network through SNMP? > >I have provided examples of products that have SNMP configurability >for their major operational compoents, are shipping and in use. Please forgive me if it is just my inability to see equivalence. Just because features are included in products, and used somewhere, does not make them practices, much less best practices. There are some QoS features in older versions of IOS I would not recommend. ;-) I was told somebody asked for them. John From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 16:47:01 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20862 for ; Mon, 14 Jan 2002 16:47:01 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA06049 for snmpconf-outgoing; Mon, 14 Jan 2002 16:38:12 -0500 (EST) Message-Id: <4.3.2.7.2.20020114162501.03782008@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jan 2002 16:36:14 -0500 To: snmpconf@snmp.com From: John Schnizlein Subject: Re: Review of draft-ietf-snmpconf-bcp-07 In-Reply-To: <20020114131753.B1324@riverstonenet.com> References: <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> <5.0.2.1.2.20020114095344.02873040@mail4.bayarea.net> <4.3.2.7.2.20020114134101.037d6d60@diablo.cisco.com> <20020114120934.D991@riverstonenet.com> <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com You have made some useful points: At 04:17 PM 1/14/2002, Michael MacFaden wrote: >You just have admire this quote from Tony Li: > Be liberal in what you accept, conservative in what you send, and add a > knob so that you can interoperate even if the other guy blows it. > >That kind of tweaking...of course it isn't a BCP. I do admire Tony's attitude and style. When I was operating a network I once had occasion for him to tell me "Just because we give you enough rope to hang yourself, doesn't mean we want you to." >>The existence of a (small fraction) of R/W MIB variables is >>not a very compelling argument for the "best practice" claim. >>Can you name the operator of a network who would say that they >>configure their network through SNMP? > >Strangely, they may or may not know they use SNMP. Maybe the correct summary is that operators who do not know what protocol they use to configure their networks use SNMP. >Customers will to me things like, I use Lucent NavisCore >or some other marketing term for an EMS product >and that is how they want to configure their network. The most important word in the immediately above is "want". But wanting to use SNMP for configuration is not the same as practicing the use of SNMP for configuration. >If you define/use SNMP read-write objects and implement the >Internet Standard Management Framework, the BCP attempts to >show how things have progressed in the past ten years or so >and what works and what to watch out for and to some extent, >what the current 'thinking' is. This appears to be an accurate description of the document. It is the current 'thinking' of those who advocate the SNMP framework. The practical point of Best Current Practice is that it requires people actually doing something well at present, not wanting to in the future. John From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 16:59:20 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21306 for ; Mon, 14 Jan 2002 16:59:20 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id QAA06357 for snmpconf-outgoing; Mon, 14 Jan 2002 16:51:38 -0500 (EST) Message-Id: <5.0.2.1.2.20020114133824.02920b70@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 14 Jan 2002 13:46:27 -0800 To: snmpconf@snmp.com From: "David T. Perkins" Subject: Re: Review of draft-ietf-snmpconf-bcp-07 In-Reply-To: <4.3.2.7.2.20020114134101.037d6d60@diablo.cisco.com> References: <5.0.2.1.2.20020114095344.02873040@mail4.bayarea.net> <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com HI, I want to clarify a misperception that is in John's message... At 02:43 PM 1/14/2002 -0500, john wrote: >I know even less about RMON probes, but since RMON is a creature of >SNMP, its configuration through SNMP would constitute configuring SNMP >features through SNMP, not configuring the network through SNMP. RMON is not a creature of SNMP. (There was a lot of marketing several years back trying to make such a claim.) RMON probes are devices that monitor network traffic (and capture packets), and allow management applications to get the statistics on the traffic. Such devices could be created that used proprietary protocols for configuring them and for retrieving stats and packets. Remote monitoring probes existed before SNMP was used to manage them. Regards, /david t. perkins From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 17:34:04 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22631 for ; Mon, 14 Jan 2002 17:34:03 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA07119 for snmpconf-outgoing; Mon, 14 Jan 2002 17:23:08 -0500 (EST) Message-Id: <200201142221.RAA10661@europa-h0001027441c5.ne.mediaone.net> Content-Type: text/plain; charset="iso-8859-1" From: "Jon Saperia " Organization: JDS Consulting, Inc. To: snmpconf@snmp.com, John Schnizlein Subject: Re: Review of draft-ietf-snmpconf-bcp-07 Date: Mon, 14 Jan 2002 17:21:19 -0500 X-Mailer: KMail [version 1.3.2] Cc: snmpconf@snmp.com References: <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> <4.3.2.7.2.20020114160749.0383f008@diablo.cisco.com> In-Reply-To: <4.3.2.7.2.20020114160749.0383f008@diablo.cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit On Monday 14 January 2002 04:17 pm, John Schnizlein wrote: > At 04:00 PM 1/14/2002, Jon Saperia wrote: > >On Monday 14 January 2002 03:47 pm, John Schnizlein wrote: > >> Can you name the operator of a network who would say that > >> they configure their network through SNMP? > > > >I have provided examples of products that have SNMP configurability > >for their major operational compoents, are shipping and in use. > > Please forgive me if it is just my inability to see equivalence. > Just because features are included in products, and used somewhere, > does not make them practices, much less best practices. > There are some QoS features in older versions of IOS I would not > recommend. ;-) I was told somebody asked for them. > > John What we are talking about are practices for use of SNMP in a configuration management context. What is in the document are approaches that have been found to work when want wants to do configuration management with SNMP. So while one may or may not like SNMP in general, or for configuration in particular, the document is only about practices that have been found helpful when one wants to use SNMP for configuration. Nothing more. As such I believe it meets the requirements for BCP as I read RFC2026. If you believe it does not, please cite why and the text in context from 2026 that shows that this document would be inappropriately called a BCP. /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 19:08:02 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26661 for ; Mon, 14 Jan 2002 19:08:01 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id SAA07986 for snmpconf-outgoing; Mon, 14 Jan 2002 18:55:55 -0500 (EST) Message-Id: <5.1.0.14.0.20020114181256.02dfaec0@mail.goldwiretech.com> X-Sender: wayne-pop@mail.goldwiretech.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 14 Jan 2002 18:52:59 -0500 To: snmpconf@snmp.com From: "Wayne F. Tackabury" Subject: Re: Review of draft-ietf-snmpconf-bcp-07 In-Reply-To: <4.3.2.7.2.20020114160749.0383f008@diablo.cisco.com> References: <200201142100.QAA10422@europa-h0001027441c5.ne.mediaone.net > <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> <20020114120934.D991@riverstonenet.com> <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 04:17 PM 1/14/2002 -0500, John Schnizlein wrote: >Please forgive me if it is just my inability to see equivalence. >Just because features are included in products, and used somewhere, >does not make them practices, much less best practices. >There are some QoS features in older versions of IOS I would not >recommend. ;-) I was told somebody asked for them. John: I'm not sure if you're trying to be facetious, but I think at this point your assertion that there are no applications of doing configuration and activation using SNMP, no applications that one can interpret a set of best practices for (to perhaps facilitate even more and better and more scalable etc. usage going further) have been pretty well shot down. I was going to add one more--MPLS optical switches which do LSP setup and traffic engineering over LSPs using SNMP-created rows. Early adopters have done this around in-progress versions of the MIBs currently under IESG review. I know of one vendor (Tenor Networks) that uses that as a selling point for their management strategy. The BCP has looked at design techniques for the kind of MIBs these devices are shipping and identified the most scalable desig...well, you've read the document, you know what it's about. If these MIBs are *shipping and in deployment now*, how can you claim that guidance on MIB design for their ilk doesn't address a *current practice*? Regards, Wayne From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 20:06:45 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28051 for ; Mon, 14 Jan 2002 20:06:44 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id TAA08737 for snmpconf-outgoing; Mon, 14 Jan 2002 19:58:33 -0500 (EST) Message-Id: <4.3.2.7.2.20020114194339.037d6c38@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jan 2002 19:56:54 -0500 To: snmpconf@snmp.com From: John Schnizlein Subject: Re: Review of draft-ietf-snmpconf-bcp-07 In-Reply-To: <5.1.0.14.0.20020114181256.02dfaec0@mail.goldwiretech.com> References: <4.3.2.7.2.20020114160749.0383f008@diablo.cisco.com> <200201142100.QAA10422@europa-h0001027441c5.ne.mediaone.net > <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> <20020114120934.D991@riverstonenet.com> <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 06:52 PM 1/14/2002, Wayne F. Tackabury wrote: >... I think at this point your assertion that there are no >applications of doing configuration and activation using SNMP, >no applications that one can interpret a set of best practices >for (to perhaps facilitate even more and better and more scalable >etc. usage going further) have been pretty well shot down. I have not made such an assertion. I have just asked, without anyone answering, for the name of a single network operator who configures their network with SNMP. If configuring through SNMP is not any operator's practice, how can it be a best practice? The question is not about the existence of applications, but the operational use of practices. Since when is shooting down a goal of an IETF WG? >Early adopters have done this around in-progress versions of >the MIBs currently under IESG review. I know of one vendor >(Tenor Networks) that uses that as a selling point for their >management strategy. In-progress MIBs as a selling point of a vendor's strategy does not make a Best Current Practice, it makes a marketing strategy. John From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 23:52:09 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04489 for ; Mon, 14 Jan 2002 23:52:09 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id XAA09961 for snmpconf-outgoing; Mon, 14 Jan 2002 23:42:51 -0500 (EST) Date: Mon, 14 Jan 2002 20:42:17 -0800 From: Michael MacFaden To: snmpconf@snmp.com Subject: Re: Review of draft-ietf-snmpconf-bcp-07 Message-ID: <20020114204217.J1862@riverstonenet.com> References: <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> <5.0.2.1.2.20020114095344.02873040@mail4.bayarea.net> <4.3.2.7.2.20020114134101.037d6d60@diablo.cisco.com> <20020114120934.D991@riverstonenet.com> <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> <20020114131753.B1324@riverstonenet.com> <4.3.2.7.2.20020114162501.03782008@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20020114162501.03782008@diablo.cisco.com>; from jschnizl@cisco.com on Mon, Jan 14, 2002 at 04:36:14PM -0500 X-Operating-System: GNU/Linux 2.4.17 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com On Mon, Jan 14, 2002 at 04:36:14PM -0500, John Schnizlein wrote: >>Customers will to me things like, I use Lucent NavisCore >>or some other marketing term for an EMS product >>and that is how they want to configure their network. > >The most important word in the immediately above is "want". >But wanting to use SNMP for configuration is not the same as >practicing the use of SNMP for configuration. Agreed. I'm sure want does not infer a CLI then either. Most 'want' a simple GUI that will contain some smarts the operator doesn't have and that often means an EMS which means programmatic access, which then leads to SNMP/TL1,etc. Here is one user you could go ask, http://www.asiaglobalcrossing.com/products_services/ds_framerelay.htm Last published report I read said they had thousands of cisco edge routers and a hundreds of Junipers in the core. Now if we went around asking for what everyone *wants*, my guess would be something like this: a) provide simple technology to begin with aka 'disk drive' as Randy mentioned so all one needs to set is the ide jumper and install it, no monitoring other than having to listen to the blasted thing wheeze and deal with corrupt filesystems or disk full conditions and the occaisonal backup. No MEDS, no LocalPrefs, no Communities to worry about or interoperability issues with other disk drives. b) vendor provided free highly skilled engineer to hunker down over a CLI and keep those pesky protocols and devices going so their service remains intact. Mike MacFaden From owner-snmpconf@seymour39.SNMP.COM Mon Jan 14 23:53:55 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04510 for ; Mon, 14 Jan 2002 23:53:55 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id XAA09999 for snmpconf-outgoing; Mon, 14 Jan 2002 23:45:45 -0500 (EST) Date: Mon, 14 Jan 2002 20:45:12 -0800 From: Michael MacFaden To: snmpconf@snmp.com Cc: amehta@riverstonenet.com Subject: snmpconf Re: diagmgr Message-ID: <20020114204512.L1862@riverstonenet.com> References: <3C437ECB.C40E955F@riverstonenet.com> <20020114192412.D1862@riverstonenet.com> <3C43A1D7.CEFC450B@riverstonenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C43A1D7.CEFC450B@riverstonenet.com>; from rjosyula@riverstonenet.com on Mon, Jan 14, 2002 at 07:28:23PM -0800 X-Operating-System: GNU/Linux 2.4.17 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com On Mon, Jan 14, 2002 at 07:28:23PM -0800, Ravi Josyula wrote: > >As of now, they are not different. The diagmgr will talk to the helpers >also. I duplicated it because I thought they might end up looking >different. Maybe, we can use the same APIs. Yeah, I'd hope you would factor the code into some library that both programs use. I'm sure code changes will be easier to get right then. >I am a bit concerned about end-ian issues. As I use the same protocol for >all show commands, I need to marshal it and as of now, I marshal as a byte >stream into the message and I demarshal it. What if the front end and back >end are different platforms? I need to talk to Brian in detail about this >before he leaves! Indeed. > >Thanks, >Ravi. > From owner-snmpconf@seymour39.SNMP.COM Tue Jan 15 00:23:48 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04827 for ; Tue, 15 Jan 2002 00:23:48 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id AAA11017 for snmpconf-outgoing; Tue, 15 Jan 2002 00:11:24 -0500 (EST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John Schnizlein Cc: snmpconf@snmp.com Subject: Re: Review of draft-ietf-snmpconf-bcp-07 References: <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> <20020111175900.K1364@riverstonenet.com> <0D7FC1D8D861D511AEA70002A52CE5E6F9C245@zcard0ke.ca.nortel.com> <4.3.2.7.2.20020114085624.03295f08@diablo.cisco.com> <5.0.2.1.2.20020114095344.02873040@mail4.bayarea.net> <4.3.2.7.2.20020114134101.037d6d60@diablo.cisco.com> <20020114120934.D991@riverstonenet.com> <4.3.2.7.2.20020114162501.03782008@diablo.cisco.com> Message-Id: Date: Mon, 14 Jan 2002 18:12:41 -0800 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > This appears to be an accurate description of the document. > It is the current 'thinking' of those who advocate the SNMP framework. > The practical point of Best Current Practice is that it requires > people actually doing something well at present, not wanting to in > the future. i think you could say this is the best current practice if you use snmp for configuration. and it should mention that, unfortunately, very few folk use snmp for configuration and almost all use snmp for monitoring. randy From owner-snmpconf@seymour39.SNMP.COM Tue Jan 15 03:15:48 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15118 for ; Tue, 15 Jan 2002 03:15:48 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id DAA19852 for snmpconf-outgoing; Tue, 15 Jan 2002 03:07:35 -0500 (EST) Date: Tue, 15 Jan 2002 09:06:59 +0100 From: David Partain Subject: Re: Review of draft-ietf-snmpconf-bcp-07 In-reply-to: <4.3.2.7.2.20020114162501.03782008@diablo.cisco.com> To: snmpconf@snmp.com Message-id: <0GPY00M5SZVOT4@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: <4.3.2.7.2.20020114153940.03769880@diablo.cisco.com> <4.3.2.7.2.20020114162501.03782008@diablo.cisco.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Hi, Regarding the discussion of whether the BCP should be a BCP, I would like to quote RFC 2026 "The Internet Standards Process -- Revision 3", page 16, in the middle of the page: The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. I think, given statements like "the community's best current thinking" and "what is believed to be the best way to perform some operations", that our "BCP" certainly qualifies to be called a "BCP". The document identifies what "is believed to be" the best way to do configuration with SNMP and represents the SNMP communities "best current thinking" on how to do that. I understand that there are people who don't think that SNMP _should be_ or _is_ used for configuration. I do think, though, that various mail sent recently adequately demonstrates that SNMP is used for configuration even if not even close to ubiquitously. That doesn't seem to me to be the question, though. Does this document represent "what is believed to be the best way to perform some operations" and "the community's best current thinking" about SNMP-based configuration? I believe so. Cheers, dlp From owner-snmpconf@seymour39.SNMP.COM Tue Jan 15 09:58:11 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25808 for ; Tue, 15 Jan 2002 09:58:10 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA29775 for snmpconf-outgoing; Tue, 15 Jan 2002 09:48:13 -0500 (EST) Message-ID: <3C43ED18.570DDF5F@verio.net> Date: Tue, 15 Jan 2002 03:49:28 -0500 From: "Carl W. Kalbfleisch" Organization: Verio X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf naive question on SNMP References: <200201102016.PAA14653@seymour4.snmp.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 Jeff Case wrote: > > system applications mib and applications mib > applmib-request@verio.net or check with carl, cwk@verio.net > The address is applmib-request@ietf.verio.net This list is extremely quite as the working group has been inactive for some time now. Maybe it will reactivate for some revisions someday! Carl -- Carl W. Kalbfleisch www.verio.net From owner-snmpconf@seymour39.SNMP.COM Tue Jan 15 10:35:47 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29271 for ; Tue, 15 Jan 2002 10:35:46 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA01030 for snmpconf-outgoing; Tue, 15 Jan 2002 10:25:24 -0500 (EST) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6FF35BE@zcard0ke.ca.nortel.com> From: "Glenn Waters" To: snmpconf@snmp.com Subject: RE: Review of draft-ietf-snmpconf-bcp-07 Date: Tue, 15 Jan 2002 10:24:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19DD8.CAEF6D30" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19DD8.CAEF6D30 Content-Type: text/plain; charset="ISO-8859-1" > -----Original Message----- > From: David Partain [mailto:David.Partain@ericsson.com] > Sent: Tuesday, January 15, 2002 3:07 > To: snmpconf@snmp.com > Subject: Re: Review of draft-ietf-snmpconf-bcp-07 [...] > I think, given statements like "the community's best current > thinking" and "what is believed to be the best way to perform > some operations", that our "BCP" certainly qualifies to be > called a "BCP". The document identifies what "is believed to > be" the best way to do configuration with SNMP and represents > the SNMP communities "best current thinking" on how to do that. I think that some clarification from the standards gurus is called for here. Point 1: My rough understanding of BCP is that it describes the best way to perform an existing practice. The term *thinking* implies something that *may not* be in use and hence is not a "Practice". As I said in my review I find that some of the document does indeed describe in use practices. I think other parts of the document (particularly sections 4 and 5) are somewhat experimental and/or informational in nature. Point 2: My rough understanding of BCP is that it describes something that is commonly accepted. I think that many parts of the document describe interesting stuff but the stuff is not commonly accepted and hence not "Best" and possibly not "Current" (but it is a "Practice") Enough said on this. Standards gurus go to work on this one. Cheers, /gww ------_=_NextPart_001_01C19DD8.CAEF6D30 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Review of draft-ietf-snmpconf-bcp-07

> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson= .com]
> Sent: Tuesday, January 15, 2002 3:07
> To: snmpconf@snmp.com
> Subject: Re: Review of = draft-ietf-snmpconf-bcp-07

[...]
 
> I think, given statements like "the = community's best current
> thinking" and "what is believed to be = the best way to perform
> some operations", that our "BCP" = certainly qualifies to be
> called a "BCP".  The document = identifies what "is believed to
> be" the best way to do configuration with = SNMP and represents
> the SNMP communities "best current = thinking" on how to do that.

I think that some clarification from the standards = gurus is called for here.

Point 1:

My rough understanding of BCP is that it describes = the best way to perform an existing practice.

The term *thinking* implies something that *may not* = be in use and hence is not a "Practice".

As I said in my review I find that some of the = document does indeed describe in use practices. I think other parts of = the document (particularly sections 4 and 5) are somewhat experimental = and/or informational in nature.

Point 2:

My rough understanding of BCP is that it describes = something that is commonly accepted. I think that many parts of the = document describe interesting stuff but the stuff is not commonly = accepted and hence not "Best" and possibly not = "Current" (but it is a "Practice")

Enough said on this. Standards gurus go to work on = this one.

Cheers, /gww

------_=_NextPart_001_01C19DD8.CAEF6D30-- From owner-snmpconf@seymour39.SNMP.COM Tue Jan 15 11:19:53 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01079 for ; Tue, 15 Jan 2002 11:19:52 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA01910 for snmpconf-outgoing; Tue, 15 Jan 2002 11:00:57 -0500 (EST) Message-ID: <000901c2bcae$2b795ae0$0301a8c0@tom3> From: "Tom Petch" To: Subject: Re: Review of draft-ietf-snmpconf-bcp-07 Date: Wed, 15 Jan 2003 12:23:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit I have made extensive use of SNMP to configure routers; in fact, I've known it be the standard way of doing it once the initial IP/SNMP support is configured into the router. This is in a high availability, high security environment, using vendor-provided tools and (of course) vendor proprietary MIB. But I am talking Enterprise, not Operator, which is why I stayed quiet at Salt Lake City. Tom Petch, Network Consultant nwnetworks@dial.pipex.com From owner-snmpconf@seymour39.SNMP.COM Tue Jan 15 11:38:18 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01867 for ; Tue, 15 Jan 2002 11:38:18 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA02468 for snmpconf-outgoing; Tue, 15 Jan 2002 11:21:57 -0500 (EST) Message-Id: <4.3.2.7.2.20020115111619.0187c780@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Jan 2002 11:20:17 -0500 To: snmpconf@snmp.com From: John Schnizlein Subject: Re: Review of draft-ietf-snmpconf-bcp-07 In-Reply-To: <000901c2bcae$2b795ae0$0301a8c0@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 07:23 AM 1/15/2003, you wrote: >I have made extensive use of SNMP to configure routers; in >fact, I've known it be the standard way of doing it once the >initial IP/SNMP support is configured into the router. This >is in a high availability, high security environment, using >vendor-provided tools and (of course) vendor proprietary >MIB. Are you using SNMPv3? How do you manage keys? How do you control which administrators can write which variables? Could you please identify the router and vendor-provided tools? >But I am talking Enterprise, not Operator, which is why I >stayed quiet at Salt Lake City. Whoever operates the network is what matters, not whether it is a commercial service provider or within an enterprise. >Tom Petch, Network Consultant >nwnetworks@dial.pipex.com John From owner-snmpconf@seymour39.SNMP.COM Wed Jan 16 02:36:14 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02162 for ; Wed, 16 Jan 2002 02:36:13 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id CAA22915 for snmpconf-outgoing; Wed, 16 Jan 2002 02:20:13 -0500 (EST) From: hlpeth@hss.hns.com X-Lotus-FromDomain: HSS To: snmpconf@snmp.com Message-ID: <65256B43.00282D4E.00@sandesh.hss.hns.com> Date: Wed, 16 Jan 2002 12:50:40 +0530 Subject: Re: Review of draft-ietf-snmpconf-bcp-07 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I would like to share some of my experience with SNMP for configuration. I am working in developing the management solution for softswitches in a carrier grade environment. SNMP is being used as the management protocol. Customer input especially for embedded solutions look for minimal configuration at run time on the EMS. Most of the SNMP object have pre-defined default values and the configuration gets done during startup or is read from a persistent storage file. SNMP is used majorly for monitoring and SNMP traps. For OEM/Switches SNMP makes more sense as a configuration interface. For service provider segment file based configuration profiles are more widely used and SNMP is used for monitoring. -- harish From owner-snmpconf@seymour39.SNMP.COM Wed Jan 16 13:20:01 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16536 for ; Wed, 16 Jan 2002 13:20:00 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA08716 for snmpconf-outgoing; Wed, 16 Jan 2002 13:03:23 -0500 (EST) Message-ID: <003d01c2bd89$62e8fa40$0301a8c0@tom3> From: "Tom Petch" To: Subject: Re: Review of draft-ietf-snmpconf-bcp-07 Date: Thu, 16 Jan 2003 17:59:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit The router manufacturer supplied the GUI tool (running under Windows) which generated both a script file which could be run as a sort of CLI and an 'online' download using SNMP and it was the latter we used. This meant it was easy to implement change control and backout if and when things went wrong at 0600 on Sunday morning, with a central database of current and historic configurations. SNMP download is so easy that a half-asleep, inexperienced human could get it right. I never even saw an OID (apart from a trace taken from curiosity) although I did have to select and specify community names and enable the appropriate UDP ports (UDP is bad news in a secure environment). I did wonder at what level the objects operated, like was it 'when I write to this, take it and execute it as if it had come from an API or CLI' as opposed to having a separate variable name for eg set port 2/7 to FDX. SNMP is v1 with security achieved by a hardened system using standard techniques eg different networks with different levels of trust separated by firewalls, users could not introduce their own code to workstations (no A-drive, regular scans of C-drive for unexpected executables), making IP addresses trustworthy (DHCP a four-letter word, LAN ports disable on change of MAC address), extensive logging of anything that might be an attempted hack etc etc Tom Petch, Network Consultant nwnetworks@dial.pipex.com +(44) 192 575 3018 -----Original Message----- From: John Schnizlein To: snmpconf@snmp.com Date: 15 January 2002 17:11 Subject: Re: Review of draft-ietf-snmpconf-bcp-07 >At 07:23 AM 1/15/2003, you wrote: >>I have made extensive use of SNMP to configure routers; in >>fact, I've known it be the standard way of doing it once the >>initial IP/SNMP support is configured into the router. This >>is in a high availability, high security environment, using >>vendor-provided tools and (of course) vendor proprietary >>MIB. > >Are you using SNMPv3? How do you manage keys? >How do you control which administrators can write which variables? >Could you please identify the router and vendor-provided tools? > >>But I am talking Enterprise, not Operator, which is why I >>stayed quiet at Salt Lake City. > >Whoever operates the network is what matters, not whether it is >a commercial service provider or within an enterprise. > >>Tom Petch, Network Consultant >>nwnetworks@dial.pipex.com > > >John > > From owner-snmpconf@seymour39.SNMP.COM Tue Jan 22 17:25:45 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13209 for ; Tue, 22 Jan 2002 17:25:44 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA12879 for snmpconf-outgoing; Tue, 22 Jan 2002 17:14:16 -0500 (EST) Date: Tue, 22 Jan 2002 14:12:07 -0800 (PST) From: Randy Presuhn Message-Id: <200201222212.OAA16344@dorothy.bmc.com> To: djw@bbn.com, ken_sidelinger@bmc.com Subject: Re: Typo in BMC snmpconf IPR statement? Cc: bwijnen@lucent.com, iesg-secretary@ietf.org, snmpconf@snmp.com 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 Hi - > Message-ID: <3C4C1DC8.59D08D41@bbn.com> > Date: Mon, 21 Jan 2002 08:55:20 -0500 > From: David Waitzman > Organization: BBN Technologies > To: ken_sidelinger@bmc.com, rpresuhn@dorothy.bmc.com > Subject: Typo in BMC snmpconf IPR statement? > > The IPR statement BMC-SNMPCONF.txt submitted a few weeks ago by BMC makes > claims using U.S. Patent No. 5,665,081. ... > Is it possible there is a typo in your IPR posting? ... You're right. There is a typo. The correct number is 5,655,081. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-snmpconf@seymour39.SNMP.COM Tue Jan 22 18:01:07 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14008 for ; Tue, 22 Jan 2002 18:01:06 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA13543 for snmpconf-outgoing; Tue, 22 Jan 2002 17:52:51 -0500 (EST) Subject: snmpconf Lucy Tafler/LON/NTRS is out of the office. From: "Lucy Tafler" To: snmpconf@snmp.com Message-ID: Date: Tue, 22 Jan 2002 22:52:11 +0000 X-MIMETrack: Serialize by Router on CHI-G01/SVR/NTRS(Release 5.0.9 |November 16, 2001) at 01/22/2002 04:48:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I will be out of the office starting January 18, 2002 and will not return until February 18, 2002. If you would like to contact me, try lucy@smuggits.com. Thanks From owner-snmpconf@seymour39.SNMP.COM Sat Jan 26 13:48:10 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09595 for ; Sat, 26 Jan 2002 13:48:09 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA16568 for snmpconf-outgoing; Sat, 26 Jan 2002 13:36:09 -0500 (EST) Message-Id: <4.3.2.7.2.20020126103033.02667790@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 26 Jan 2002 10:33:27 -0800 To: snmpconf@snmp.com From: Andy Bierman Subject: review of draft-ietf-snmpconf-pm-09.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_695459688==_" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --=====================_695459688==_ Content-Type: text/plain; charset="us-ascii" --=====================_695459688==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="snmpconf_pm_09_review.txt" Review of draft-ietf-snmpconf-pm-09.txt Andy Bierman I will try not to list issues already raised by Dave Harrington. In general, there are some very powerful features in this complex MIB. The document lacks clarity and organization in some aspects, which makes it difficult to understand. I attended some SNMPCONF WG meetings, and talked to the authors at length about the design, and it was still very difficult to figure out the big picture or specific complex interactions, by reading the draft. (It's an Easter Egg hunt to figure out any particular feature.) [pg 4, sec 3, Overview] There were so many good slides presented in the WG describing the layering from independent to dependent data abstractions, but none of that made it into the draft. (The entire overview is less than a page.) There is no attempt to describe how this draft addresses any of the motherhood & apple pie goals listed in para 2. There is no attempt (anywhere in the draft) to describe the overall system that is defined within the draft. The draft reads like a parts list without instructions on how to put all the parts together. Some of the missing details: - a diagram showing the components of the PM system - a diagram showing how the PM system fits within the overall managed device - a diagram showing how the PM system fits within the overall NM system as a mid-level manager - explanations of all the components, such as: - element discovery - element registration - capabilities registration - roles - policies - policy groups - policy selection - policy distribution - policy organization - policy conditions - policy actions - policy scheduling - policy script execution environment - element filtering - accessor library - policy validation - schedule group - how the components relate to each other - how the entire system fits within the SNMP Architecture [pg 5, sec 4, Arch.] This section would make more sense if the system was explained first. This section doesn't really describe an architecture, but rather the notion of policy based management (again). It doesn't really explain the system that implementors are supposed to create, and how operators are supposed to use it. [pg 6, para 1, sec 4, Arch.] The description of "this element" is confusing because there has been no detailed explanation (and won't be) of the runtime environment. [pg 7, para 3, sec 4, Arch.] Accessor functions have not yet been introduced, so this para seems out of place. [pg 7, para 4, sec 4, Arch.] "The role group ..." sounds like you are introducing a term, but I think this refers to a MIB group. Clarify. [pg 8, para 1, sec 4, Arch.] (M-F 9-5) should be expanded to full words [pg 8, para 2, sec 5.1, Terminology] This section should be moved to a general terms section either before or after the overview. The details about RTE should stay in section 5. Some terms that need introduction: - element type - element - "this" element - system element 0.0 - role - policy - policy group - policy condition - policy action - accessor function - schedule group - precedence group [pg 8, para 4, sec 5.2, Element Discovery] "as 1 element" -> "as one element". In the last sentence, it's not clear how this applies to the runtime environment. It would help to explain the runtime environment at a high-level (iterative engine, and how it operates on elements) somewhere in section 5. [pg 9, sec 5.2, Element Discovery] It isn't clear why the details of the element registration MIB are explained, because the rest of the discussion is about element discovery. How does NMS registration relate to discovery? It is confusing to mix MIB object details in with this high level discussion. (They should be in a separate MIB overview section.) In general, the MIB objects are discussed in detail before the MIB is introduced. [pg 10, sec 5.2,1 Implementation Notes] This section should be moved to later in the document. because the MIB has not been introduced, and all the implementation notes should be grouped together. [pg 11, para 2, sec 5.3 Element Filtering] This first paragraph contains MIB details about policy scheduling, and should go in a section for that (added before this one). This concept is called 'policyCondition' everywhere but this section. [pg 11, sec 5.3,1 Implementation Notes] "It is an implementation-dependent matter as to how policy conditions are scheduled." This is pretty much the entire description of the script invocation and scheduling details. I think it will be difficult for script developers to port scripts across PM implementations with this approach. There are also many constraints placed on scheduling throughout the document, so this statement is misleading. [pg 11, sec 5.4 Policy Enforcement] This concept is called 'policyAction' everywhere but this section. [pg 12, sec 5.4,1 Implementation Notes] I think it will be difficult for script developers to port scripts across PM implementations without specifying scheduling algorithms, scheduling conflict resolution, etc.) It is not clear what by the 2nd setence "each ... pair its own process ... run simultaneously." The execution control flow should be explained (from engine to condition script to action script within a specific iteration sequence, based on registered elements, configured latencies, system events, etc.) [pg 12, sec 5.5, Definitions] These terms should be moved to a general Terms section. set to 'active -> set to 'active' If their -> If there term "precedence policy" should be explained in the Terms section [pg 13, para 2, sec 6, PolicyScript Language] It is a real stretch to call this language a subset of C++, and talk about operator overloading solely as an aid to documentation. The added features like 'var' class or '$*' construct in strings, specialized execution environment, lack of user-defined functions or data types, lack of step-debugging, and monolithic code organization make this language (and programming environment) very different than C++. [pg 13, para 4, sec 6, PolicyScript Language] "This language is formally defined as a subset of ISO C++ [19]," I don't think this is true. The 'var' and '$' features are not part of C++. An "extended subset" is marketing-speak for "new language". [pg 13-14, para 6, sec 6, PolicyScript Language] "within a PolicyScript program"; do you really mean within an single instance of a policy script? The term 'PolicyScript program' is not used in other places. [pg 18, para 2, sec 6.2, Variables] "typedef ... var;" This example is meaningless and confusing, since there are no typedefs in this language. This and the last para should be clarified or removed. [pg 18, last para, sec 6.2.1, Var Class] It is very confusing to define these operators and use them in examples, and bury in the text that they are not really part of the language. This should be in a separate section on Operators. [pg 19, para 4, sec 6.2.1, Var Class] Why is the EBNF for numeric_string in this section instead of 6.1) Formal Definition? Why do you need EBNF for something that's not in the language? [pg 21, para 1, sec. 6.2.1, Var Class] These rules seem to belong with the formal definition in sec 6.1 The term 'OP' is confusing because it is not explained, and it looks like there should be a construction for OP. It's being used in a generic sense, so a term like would be more clear. [pg 22, para 3, sec. 6.2.1, Var Class] "getVar("ifSpeed.$*") < 128000" This example is confusing because the string 'ifString' isn't actually allowed, and the "$*" mechanism has not been introduced or defined yet. "an integer than" -> "an integer, then" [pg 22-23, sec. 6.3, QuickStart Guide] It's very confusing to start out with a gibberish example. Most people will glaze over the explanation for why it's there and attempt to figure out what the code is trying to accomplish. The Quickstart guide should be moved to a later section because the rest of the language and runtime features have not been introduced yet, so this section is full of forward references. "return (inSubtree(elementName(), "ifEntry")" This example is misleading because the string 'ifEntry' is not actually allowed. In general, it's a bad idea to provide code examples that won't actually work. People learn from examples, so they should be correct. The other examples of finding the gold interface or killing all application processes that have run for > 5 min are not very compelling. IMO. the document doesn't effectively demonstrate that the PM MIB can be used to perform the initial configuration of a real managed device, such as a router. [pg 26, para 1, sec 6.4, return values] Does the 1st sentence on this page mean that all policy scripts are required to return a Boolean value, and the only time they don't is if an RTE occurs? The structure of the policy scripts should have been explained already. None of the examples to this point have returned a value -- they show the opposite (simple 'return;'); It is confusing to define PolicyCondition and PolicyAction scripts as if they're the same, and then sprinkle text throughout the document that says the opposite (e.g. all scripts return a Boolean, but all PolicyAction return codes are ignored.) This doesn't make PM easier to understand or use. It should be more clear that a script is very dependent on the element type is is intended to act upon. Execution of a script on the wrong element type, or a wrong parameter in a call to 'ev()' could cause incorrect results and be hard to detect. [pg 27, sec 8, Accessor Functions] Why are assessor libraries registered in the role table instead of the capabilities table, and accessed with 'roleMatch'? There are no mechanisms to add new accessor functions or change an accesssor function over time. The ability to determine that a PM platform supports every possible parameter for every accessor function in a library, or determine nothing at all, is not very useful. Vendors will probably register libraries even if they don't support every option to every function. [pg 29, sec 9.1.1, SNMP Operations] >From time -> From time "function(...[, integer mPModel, string tDomain, string tAddress, integer secModel, string secName, integer secLevel, string contextEngineID ])" This function prototype is confusing, function looks like a keyword, and ... is legal is C, but not the first param. Add a real example just after this to show what a real function prototype with these extra parameters would look like. Explain up-front that these are called 'NonLocalArgs' throughout the document, instead of at the end on pg 31. [pg 30, sec 9.1.1, SNMP Operations] ascii -> ASCII (throughout document) [pg 31, sec 9.1.2, Form of SNMP Values] ToInteger() function -> ToInteger() operator The 'enum_decimal' EBNF should be in section 6.1, Formal Definitions, not here. [pg 32, sec 9.1.2, Form of SNMP Values] The paragraph explaining that "ifIndex" is not actually encoded on the wire is incomplete. Scripts passing parameters to accessor functions are also affected, not just setting MIB objects that happen to have a syntax of OBJECT IDENTIFIER. [pg 35, sec 9.1.3.4, searchColumn] no distinct section for the 'pattern' parameter [pg 36, sec 9.1.3.4, searchColumn] set to the oid of -> set to the OID of (all instances of oid should be capitalized unless refering to the 'oid' parameter to an accessor function.) example with "ifType" is misleading because this string value is not actually allowed. [pg 37, sec 9.1.3.5, setRowStatus] It's not clear why or when this function should be used instead of createRow. Some explanation would help. A code example of this accessor function would help. [pg 39, sec 9.1.3.6, createRow] There should be a distinct section explaining the 'index' parameter. [pg 42, sec 9.1.4, General SNMP Functions] readVar and writeVar -> readVar, and writeVar arrays and -> arrays, and varbindlist -> varbind list [pg 43, sec 9.1.4, General SNMP Functions] "writeVar(pdu, nVars++, "sysDescr.0", ...);" Code examples should only contain valid syntax. This is confusing because the "..." is valid C syntax for function prototypes, but PolicyScript doesn't have prototypes, and the example is a code fragment anyway. Why would a varbind get created automatically by a readVar or snmpSend operation? Is this a typo? Seems like only writeVar should actually create a varbind in a PDU data store. Is there a maximum number of varbinds allowed in this data store? The writeVar code examples would be more helpful in section 9.1.4.2. [pg 44, sec 9.1.4.2, writeVar] Does this function have a return code? It isn't documented. [pg 45, sec 9.1.4.3, readVar] Does this function have a return code? It isn't documented. Some code examples for readVar would be helpful. and it's type -> and its type [pg 46, sec 9.1.4.4, snmpSend] The values for the opcode parameter are 'defined elsewhere', yet later on the same page the opcode Trap(4) is given as an example. The opcodes should be listed or a specific reference given. [pg 47, sec 9.1.4.6, writeBulkParameters] Are there any ordering issues between writeVar and writeBulkParameters, besides that they both have to be called before a GetBulk PDU is sent with the snmpSend function? Is it an error in snmpSend if the number of varbinds present is not > the nonRepeaters parameter? [pg 47, sec 9.1.4, general] These functions are very important and it would help to have a meaningful example that used all of them. [sec 9, general] It is short-sighted to place all of the accessor functions in one library, and place that library in the PM spec itself. The inability to ever change anything in a library after initial publication is also a significant weakness. It would help implementors to have a header file with the complete and correct prototype for every function in an accessor library, in a concise form. There seems to be no recognition of vendor provided accessor libraries, other than registering the library name as a capability to check with roleMatch("libname", "0.0");. Some accessor function prototypes start with a return value (like C) and others start with the function name (means an int is returned in K&R C, what does it mean here?) All the accessor prototypes should be consistent. [pg 48, sec 9.2, Constants] The examples are misleading because the 'const' keyword is used. Why not just have a table, and list Constant Name, Type, and Value in three columns. Some explanation of why the Data type constants are not sequential enums would help. Same for origin of the SNMP Error and Exception Constants. The term 'integer' is used throughout the document, except here, where the term 'int' is used instead. [pg 48-49, sec 9.2, Constants] Why are all the constants named without Caps other than the first char (e.g. Badparameter) except GeneralFailure? Some constants like noAuthNoPriv don't start with a cap. These constant names should be consistent. Mention that these constants are reserved words, and cannot be used for any variable or accessor function name. That is the case, right? All system constants should be listed in this section. Some are spread out in other sections (e.g. 9.3.9). [pg 50, sec 9.3.1, roleMatch] "'roleString' is a string. The optional argument 'element' contains the OID name of an element, defaulting to the current element if 'element' is not supplied." Isn't there more to say about the 'roleString' param? Is the HEX encoding of contextEngineID defined somewhere else? Meaningful examples of this accessor function would help. [pg 52, sec 9.3.7, setScrathpad] The concept of scope should be buried in this accessor function definition. These definitions (Global, Policy, PolicyElement) should be explained along with the use of scratchpads, in a previous section on execution environment. It's not clear that the scope values are constants, because they are defined later (pg 55). There are minimum requirements on the newPDU() function (5 per invocation, 64 varbinds each). There should be minimum requirements for the number of scratchpad variables as well. [pg 54, sec 9.3.8, getScrathpad] There doesn't seem to be any way to discover or dump all or some of a scratchpad contents for debugging purposes. Unless the same string is used for 'varName' as in the setScratchpad call, the variable is invisible to the application. The list of usage examples is very confusing, not just because of the "== 55" constructs that should be "--> 55", but it's hard to tell what the example is trying to point out. (I think it's the effect of the scope parameter on the values set and retrieved.) [pg 55. sec 9.3.9, Constants] This section should be moved to a centralized constants section, and the const keyword avoided (see above). Same consistent naming comment as above. [pg 55. sec 9.3.10, signalError] The last sentence is confusing and should be changed or removed. ("script no longer calls this function" ... ?) Is the agent required to detect the setting of these signalError bits immediately? Is there a max latency for this event defined? It should be mandatory to check this at each control point (although the spec doesn't define control point in the runtime section.) An accessor function that causes an action (e.g. snmpSend or setScratchpad) must not be called after an RTE occurs or signalError is called. Does it say that somewhere? [pg 56. sec 9.3.11, defer] The grammar in last sentence is incorrect (bronze policy isn't.) The concept of precedence groups should be explained way before here, in an accessor function description. The whole concept is fuzzy, potentially complicated, and never explained or shown in examples. How is the system configured to utilize "runner-up" policies? The mechanism should be better explained. the code determines -> the policy script determines The defer prototype should be formatted in a consistent manner, with a return code. The parameter should not be the same as the function name. "If defer(0) is called, the script will not defer." What does this sentence mean? What is the point of calling defer with a parameter value of zero? The parameter seems useless. Does defer cause an RTE if there is nothing to defer to, or an RTE in any other cases? The debugging message (present for 'fail') would also be useful for debugging scripts using the defer function. It should be extra clear that the defer call is like a return statement, and no code after this line will actually be executed. An example would help here. [pg 57. sec 9.3.12, fail] "If 'defer' is 1, this script will defer to the next lower precedence ready policy in the same precedence group whose condition matches. If 'defer' isn't 1, it will not defer. Note that if a condition defers, it is functionally equivalent to the condition returning false." This defer parameter is confusing. The runtime environment should be defined clearly in one place, instead of scattering tidbits like this throughout the document. Not clear what the last sentence of this para is supposed to mean. Does the fail (or defer) function force a specific return value for a policy script? Isn't it always false, even though it's ignored by the PM agent? The free parameter seems to control whether the function exit is treated as an RTE or not. It doesn't explicitly cause anything to be freed unless 'freeOnException' was previously set. The free parameter seems useless because the scope of a variable (which previously called newPDU) can only be global to a single script invocation. Even if defer==1, any such PDUs will be freed by the agent upon exit of the script calling fail. It should be extra clear that the fail call is like a return statement, and no code after this line will actually be executed. An example would help here. [pg 57. sec 9.3.13, getParameters] >From time -> From time may desire -> may require Mention that this string is only set via the pmPolicyParameters MIB object. [pg 58. sec 9.3.13, getParameters] getVar("ifSpeed.$*") < integer(getParameters()) // The call to 'integer()' is meant to force a numeric '<' // operator instead of the string comparison that normally would // result from comparing two strings. This is a forward reference to the integer() function. The comment needs to be reformatted because 'would' wrapped. Then one can store -> In this example, to cause -> will cause [pg 58. sec 9.4.1, regexp] Example code showing meaningful usage of the match parameter would be helpful. [pg 58-59. sec 9.4.2, regexpReplace] Example code would be helpful. Are there restrictions on the value of 'replacement'? Does an RTE occur if the string replacement causes the 'src' string to overflow? [pg 60. sec 9.4.8, oidSplice] What happens if offset > oidlen(oid1)? The oid1 may be extended even if offset + len < oidlen(oid1). The text also implies that oid1 will be padded with some unspecified value. [pg 62. sec 9.4.9, parseIndex] An example for each variant of the function would be helpful. It would help in the example to show what OID fragment values are actually stored in each var = parseIndex() call. The example is misleading because the string ipForwardIfIndex is not actually allowed. How does the agent know where the instance portion begins in the arbitrary OID passed in 'oid'; What does the function return if index > oidlen(oid), or if type==Oid and len==0, and the count octet read is > the length of the remaining OID fragment? This function is confusing because of the complex parameter overloading. [pg 63. sec 9.4.11-13, integer, string, type] These accessor functions should be explained earlier and mentioned with the sections on ToInteger and ToString. It is very confusing to see all the ToInteger() text throughout the document, and then find the accessor functions with different names. It would be much more clear and consistent if the ToFoo operators were removed and replaced with these accessor functions. Meaningful code examples of these functions would help. [pg 64. sec 9.4.14-16, chr, ord, substr] Meaningful code examples of these functions would help. "abs(len) octets" : the abs() function is not defined anywhere. [pg 65. sec 9.5, Library Accessor Functions] The full function prototypes for these POSIX functions should be provided. No mention of the sprintf format codes is made. How does each and every format code variant map to a data type in PolicyScript? Is an RTE generated if the number of parameters passed to sprintf does not match the format string? Is an RTE generated if the type of a parameter passed to sprintf does not match the format string type? [pg 65. sec 10, Schedule Table] There is no overall explanation of time-based scheduling. This should be in the section on the runtime environment. This section is out of place here. The term 'schedule group' is used here but not defined anywhere. The discussion of the pmScheduleTable should be in an overview of the MIB. and it's conditions -> and its conditions it's pmPolicySchedule variable -> its pmPolicySchedule variable [pg 68. sec 11, Definitions] There is no overview section to introduce the MIB groups as is customary in standard MIBs. The MIB is harder to read because of this omission. A diagram showing the different groups in the MIB and explanations of each group and its relationship to the other groups (if relevant) would be helpful. [pg 69. sec 11, UTF8String] The UTF8String TC seems very generic, and not specific to PM at all. It should be defined in a more general TC document, not here. the 10646 standard -> the ISO/IEC IS 10646 standard or the 10646 standard -> this standard [pg 72, sec 11, pmPolicyIndex] This description is rather terse, I guess because this INDEX component isn't really used for anything. It could have served as the pmPolicyPrecedence, but I suppose the WG figured out a corner case where it helps to have a arbitrary local integer separate from the policy precedence. [pg 72, sec 11, pmPolicyPrecedenceGroup] There are no examples of this potentially complicated mechanism in the document. Many runtime environment features (like this one) are explained and defined via MIB objects, which makes them hard to figure out. [pg 72, sec 11, pmPolicyPrecedence] it's action -> its action The complex runtime behavior should be defined in a section on the runtime environment. The document says scheduling an implementation-specific matter, but there are little rules scattered throughout the document that contradict that statement. Why is precedence tie-breaking left to the implementor? This will make scripts hard to port. It's easy enough to pick an algorithm (e.g. highest pmPolicyIndex wins). [pg 73, sec 11, pmPolicySchedule] Is the terminology used here inconsistent? Other objects refer to a ready policy, not an active policy. The complicated interactions between precedence groups and schedule groups deserve some mention in the MIB overview section. Debugging could be interesting, especially since the agent isn't even required to resolve a precedence conflict the same way each time. (This means a different policyAction can run each time as well.) [pg 75, sec 11, pmPolicyActionScriptIndex] The term pmPolicyAction is not used anywhere else. This should be policyAction. [pg 76, sec 11, pmPolicyConditionMaxLatency] "... may wish to re-run .. change to the role strings" This is another execution environment tidbit scattered in the document. All of these should be collected and placed outside the MIB description clauses. [pg 77, sec 11, pmPolicyMaxIterations] This object is allowed to change at any time, which is difficult to implement. If an NMS lowers this object while a script is running in a while loop, will the agent instantly detect the change? On the next policy task invocation? Within some max latency? Is there a specific RTE error code for maxIterationsExceeded? I didn't see one. (I guess because there's no mechanism to expose RTE error code values anyway.) [pg 77-78, sec 11, pmPolicyTable gauges] It's not clear what the underlying execution model is, so it's also unclear what starts the counting and stops the counting for a particular gauge value. [pg 79, sec 11, pmPolicyAdminStatus] it's rowstatus set -> its rowStatus set This object refers to active policy, not ready policy. This concept should have a consistent label. It is odd that this object locks the row parameters and not the RowStatus object, but okay. [pg 80, sec 11, Policy Code Table] This long ASN.1 comment should be in a MIB overview section instead. [pg 83, sec 11, Element Type Registration Table] This long ASN.1 comment should be in a MIB overview section instead. What happens to the running script if an entry is removed from this table. What does the runtime do if the current loop is the elementType removed? Is there an RTE error code for this condition? What happens to the running script if an entry is added to this table that changes an element filter evaluation? The document never actually defines what constitutes an element type, so it's hard to tell how the agent is supposed to auto-populate this table. [pg 85, sec 11, pmElementTypeRegOIDPrefix] The "0.0" system entry is not mandatory (none are), yet there are accessor functions (like roleMatch) that need this entry. Is this entry required or do those accessor functions cause an RTE if they reference the non-existent 0.0 entry? [pg 86-87, sec 11, Role Table] This long ASN.1 comment should be in a MIB overview section instead. [pg 88, sec 11, pmRoleElement] Does this re-indexing rule apply if the element is in on a different engine? Is there a max latency for discovering re-indexing? This is a tall order, considering other text in the document says the agent doesn't really know (and doesn't enforce) the structure of the OID instance in any other cases. [pg 89, sec 11, pmRoleContextEngineID] that this role string assignment is valid for. -> for which this role string assignment is valid. [pg 90, sec 11, pmCapabilitiesEntry] This table is confusing because the indexing is flat. All other accessor functions and MIB tables account for a context and engineID (like the pmRoleTable) except this one. The scripts are supposed to act upon targets in different contexts and on different engines, but this table only provides for the capabilities of the PM agent, not the capabilities of a target element. This is broken because the PM agent capabilities are defined by this MIB. [pg 92, sec 11, pmCapabilitiesOverrideTable] It's unclear why this is a separate table, instead of combined in the pmCapabilitiesTable. If the NMS wants to disable a capability, then a read-write switch in that table (i.e. move pmCapabilitiesOverrideState to the other table). [pg 93-94, sec 11, pmCapabilitiesOverrideState] What is supposed to happen when the NMS sets this object to 'valid'? If the agent doesn't have a particular capability, then is the code for this "override MIB" supposed to magically appear in the agent when this object is set to valid? If not, then the agent doesn't really have the capability, so what is the purpose of this feature? [pg 104, sec 11, pmTrackingEPTable] Some explanation of why this table is read-create and the PETable is read-only would be nice. Does the agent ever create entries in this table? What happens when corresponding PEEntries are deleted, or the policy is disabled or deleted? [pg 105-106, sec 11, pmTrackingEPStatus] This object is read-create, but there is no RowStatus in this table. How do entries ever get deleted? "This entry will only exist if the calendar for the policy is active..." How can this be true if the NMS is creating the entry? What happens if this is set to forceOff while a policy is running? Does the script complete if it was just forced off? Does it end with an RTE? Do other MIB status objects change elsewhere in the pmPolicyTable when this is set to forceOff? exists it's value -> exists, its value [pg 106, sec 11, pmDebuggingTable] Some sort of indication of how many log entries can be supported and how long the agent keeps them would be useful. I suspect they were left out because the memory allocation can get so complicated, these objects would be hard to implement. Aa MIB object to identify an application error code (in addition to the error string) would be useful. [pg 107, sec 11, pmDebuggingElement] Why is this INDEX component read-only? It isn't used in any notification (which would be accessible-for-notify anyway). [pg 108, sec 11, pmNewRoleNotification] in it's index -> in its index [pg 112, sec 14, Acknowledgements] No mention whatsoever, or reference, is given for the Scheduling MIB, even though several hundred lines of text were lifted from that MIB. The cut-and-paste is bad enough! [pg 116, sec 17, Intellectual Property] I think different text is supposed to go here if the WG knows of any claims of patented IP pertaining to this work, and I believe BMC Software is making such a claim. [pg 118, ToC] This should go in the front of the document. [SMILINT WARNINGS] ./POLICY-BASED-MANAGEMENT-MIB:2013: [4] object identifier name `pmAbnormalTerminationNotification' longer than 32 characters ./POLICY-BASED-MANAGEMENT-MIB:801: [5] index of row `pmElementTypeRegEntry' can exceed OID size limit ./POLICY-BASED-MANAGEMENT-MIB:971: [5] index of row `pmRoleEntry' can exceed OID size limit ./POLICY-BASED-MANAGEMENT-MIB:1086: [5] index of row `pmCapabilitiesEntry' can exceed OID size limit ./POLICY-BASED-MANAGEMENT-MIB:1212: [5] index of row `pmCapabilitiesOverrideEntry' can exceed OID size limit ./POLICY-BASED-MANAGEMENT-MIB:1670: [5] index of row `pmTrackingPEEntry' can exceed OID size limit ./POLICY-BASED-MANAGEMENT-MIB:1782: [5] index of row `pmTrackingEPEntry' can exceed OID size limit ./POLICY-BASED-MANAGEMENT-MIB:1891: [5] index of row `pmDebuggingEntry' can exceed OID size limit --=====================_695459688==_-- From owner-snmpconf@seymour39.SNMP.COM Sat Jan 26 15:43:41 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10559 for ; Sat, 26 Jan 2002 15:43:41 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id PAA17028 for snmpconf-outgoing; Sat, 26 Jan 2002 15:33:07 -0500 (EST) Message-Id: <4.2.2.20020126152548.00a709a0@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 26 Jan 2002 15:31:57 -0500 To: snmpconf@snmp.com From: "Joel M. Halpern" Subject: Re: Andy's review of draft-ietf-snmpconf-pm-09.txt Cc: Andy Bierman In-Reply-To: <4.3.2.7.2.20020126103033.02667790@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com [I will re-read Andy's comments, but I noted a couple of patterns and I think that addressing the reasons for the patterns may help.] 1) A number of the comments about document structure, insufficient information, and other "errors" appear to arise from a single cause. In our efforts not to mandate a single implementation strategy, we seem to have forgotten to give the reader enough information to actually do the implementation. I overlooked this (and presumably so did the authors) because by this time in the process I have lots of assumptions in my head. However, given how frustrating it is when I have to work with other under-specified RFCs, I think that we need to look at putting a lot more descriptions of possible implementations into the document. 2) Andy comments repeatedly about strings appearing in places where they "are not allowed". It appears that Andy missed (and therefore we need to emphasis better) the fact that these strings are supposed to be processed on the front end. The fact that we are not mandating a front end, but are describing all our examples as if there is a smart front end does produce a tension (rather like the on in (1) above) that should be addressed. I actually muchly prefer the use of the text strings, as if the examples used explicit numeric OIDs I would have no idea what the examples were doing. Yours, Joel M. Halpern From owner-snmpconf@seymour39.SNMP.COM Sat Jan 26 16:20:49 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10852 for ; Sat, 26 Jan 2002 16:20:49 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id QAA17208 for snmpconf-outgoing; Sat, 26 Jan 2002 16:13:12 -0500 (EST) Message-Id: <4.3.2.7.2.20020126124555.01fcbdf8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 26 Jan 2002 13:10:33 -0800 To: snmpconf@snmp.com From: Andy Bierman Subject: Re: Andy's review of draft-ietf-snmpconf-pm-09.txt In-Reply-To: <4.2.2.20020126152548.00a709a0@mail.stevecrocker.com> References: <4.3.2.7.2.20020126103033.02667790@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 12:31 PM 1/26/2002, Joel M. Halpern wrote: >[I will re-read Andy's comments, but I noted a couple of patterns and I think that addressing the reasons for the patterns may help.] > >1) A number of the comments about document structure, insufficient information, and other "errors" appear to arise from a single cause. In our efforts not to mandate a single implementation strategy, we seem to have forgotten to give the reader enough information to actually do the implementation. I overlooked this (and presumably so did the authors) because by this time in the process I have lots of assumptions in my head. However, given how frustrating it is when I have to work with other under-specified RFCs, I think that we need to look at putting a lot more descriptions of possible implementations into the document. It's not really under-specified, but rather just not well organized. The big areas for improvement: - explain the whole before diving into the details of the parts - collect related information into one place - remove all forward references to concepts, MIB objects, and terms - make examples consistent and correct, and use lots of them - attempt the clarify the runtime behavior and document one suggested implementation strategy of the runtime environment >2) Andy comments repeatedly about strings appearing in places where they "are not allowed". It appears that Andy missed (and therefore we need to emphasis better) the fact that these strings are supposed to be processed on the front end. The fact that we are not mandating a front end, but are describing all our examples as if there is a smart front end does produce a tension (rather like the on in (1) above) that should be addressed. I actually muchly prefer the use of the text strings, as if the examples used explicit numeric OIDs I would have no idea what the examples were doing. IMO, the WG is making a flawed assumption about scripting, by requiring a front end to translate some parts of the source code before loading the pmPolicyCodeTable. Humans should be able to generate 100% of the source code without additional tools. (That's why I put an OID Alias table in the SEE MIB.) The examples should show the real ASCII-dotted OID and the string version in a comment. It is very confusing to see all those verbose disclaimers about how the code really doesn't look like this -- it's human nature to assume the authors would only include valid examples of the programming language, and base their own code on those examples. It would be extremely challenging for a non SNMPCONF WG member to fully implement the PM MIB just by reading this document, let alone getting two of them to create inter-operating implementations. >Yours, >Joel M. Halpern Andy From owner-snmpconf@seymour39.SNMP.COM Mon Jan 28 07:44:34 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23250 for ; Mon, 28 Jan 2002 07:44:34 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id HAA24334 for snmpconf-outgoing; Mon, 28 Jan 2002 07:36:16 -0500 (EST) Message-ID: <0BF8B32B723ED5119E0B0002A551748B01FA0825@corp-exc3.ctron.com> From: "Harrington, David" To: "snmpconf@snmp. com (E-mail)" Subject: review of draft-ietf-snmpconf-pm-09.txt Date: Mon, 28 Jan 2002 07:34:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A7F8.1999EA90" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A7F8.1999EA90 Content-Type: text/plain; charset="iso-8859-1" Andy observed: "[pg 116, sec 17, Intellectual Property] I think different text is supposed to go here if the WG knows of any claims of patented IP pertaining to this work, and I believe BMC Software is making such a claim." Cabletron (Enterasys) also identified to the WG three patents it has which may pertain to this work. dbh ------_=_NextPart_001_01C1A7F8.1999EA90 Content-Type: text/html; charset="iso-8859-1" review of draft-ietf-snmpconf-pm-09.txt

Andy observed:
"[pg 116, sec 17, Intellectual Property]
I think different text is supposed to go here if the WG
knows of any claims of patented IP pertaining to this work,
and I believe BMC Software is making such a claim."

Cabletron (Enterasys) also identified to the WG three patents it has which may pertain to this work.

dbh

------_=_NextPart_001_01C1A7F8.1999EA90-- From owner-snmpconf@seymour39.SNMP.COM Mon Jan 28 07:54:37 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23358 for ; Mon, 28 Jan 2002 07:54:36 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id HAA24428 for snmpconf-outgoing; Mon, 28 Jan 2002 07:45:29 -0500 (EST) Message-ID: <0BF8B32B723ED5119E0B0002A551748B01FA0826@corp-exc3.ctron.com> From: "Harrington, David" To: "snmpconf@snmp. com (E-mail)" Subject: reviews of draft-ietf-snmpconf-pm-09.txt Date: Mon, 28 Jan 2002 07:43:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A7F9.578E1870" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A7F9.578E1870 Content-Type: text/plain; charset="iso-8859-1" Hi, In November, I submitted a long list of edits that the document needed. I only did the first half of the document because many of the edits needed were repetitive and would impact the text in the rest of the document. I'm saving my time to review the revised version of the document. Given the extensive input from reciews by Andy and myself, it appears a revision is called for. When can we expect to see another revision? dbh ------_=_NextPart_001_01C1A7F9.578E1870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable reviews of draft-ietf-snmpconf-pm-09.txt

Hi,

In November, I submitted a long list of edits that = the document needed. I only did the first half of the document because = many of the edits needed were repetitive and would impact the text in = the rest of the document. I'm saving my time to review the revised = version of the document.

Given the extensive input from reciews by Andy and = myself, it appears a revision is called for. When can we expect to see = another revision?

dbh

------_=_NextPart_001_01C1A7F9.578E1870-- From owner-snmpconf@seymour39.SNMP.COM Mon Jan 28 08:24:19 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24371 for ; Mon, 28 Jan 2002 08:24:18 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA24758 for snmpconf-outgoing; Mon, 28 Jan 2002 08:16:38 -0500 (EST) Message-ID: <0BF8B32B723ED5119E0B0002A551748B01FA0827@corp-exc3.ctron.com> From: "Harrington, David" To: "'snmpconf@snmp.com'" Subject: RE: Andy's review of draft-ietf-snmpconf-pm-09.txt Date: Mon, 28 Jan 2002 08:15:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A7FD.CEE4A520" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A7FD.CEE4A520 Content-Type: text/plain Comments inline > -----Original Message----- > From: Andy Bierman [mailto:abierman@cisco.com] > > It's not really under-specified, but rather just not well organized. > The big areas for improvement: > - explain the whole before diving into the details of the parts > - collect related information into one place > - remove all forward references to concepts, MIB objects, and terms > - make examples consistent and correct, and use lots of them > - attempt the clarify the runtime behavior and document one > suggested implementation strategy of the runtime environment > These were also the cause of many of my comments. I've been involved in the snmpconf effort, and had difficulty wading through all the forward references and the little rules about implementations throughout the document. > >2) Andy comments repeatedly about strings appearing in > places where they "are not allowed". It appears that Andy > missed (and therefore we need to emphasis better) the fact > that these strings are supposed to be processed on the front > end. The fact that we are not mandating a front end, but are > describing all our examples as if there is a smart front end > does produce a tension (rather like the on in (1) above) that > should be addressed. I actually muchly prefer the use of the > text strings, as if the examples used explicit numeric OIDs I > would have no idea what the examples were doing. > > IMO, the WG is making a flawed assumption about scripting, by > requiring a front end to translate some parts of the source code > before loading the pmPolicyCodeTable. Humans should be able to > generate 100% of the source code without additional tools. > (That's why I put an OID Alias table in the SEE MIB.) > > The examples should show the real ASCII-dotted OID and the string > version in a comment. It is very confusing to see all those > verbose disclaimers about how the code really doesn't look like > this -- it's human nature to assume the authors would only include > valid examples of the programming language, and base their own > code on those examples. I have a concern that we are giving examples that do not reflect what the language actually supports. I feel that the reason this is being done is that nobody would be able to understand the scripts if the supported formats were used everywhere. But we expect operators to write interoperable scripts without the benefit of writing it with text names. If people involved in SNMP as much as we are cannot make sense of a script "snippet" if it is written with OIDs, imaging the state we are forcing on an operator who needs to configure policies for a complete router using complex scripts that contain only the raw OIDs and raw parameters. While I agree with Andy that it is undesirable to force users to use an application to write meaningful scripts, I suspect that many in this WG assume there will be a pre-processor involved. We don't make that easy for users; do the expected preprocessors contain hard-coded aliases for known OID equivalents?. If we expect operators to use a preprocessor why don't we provide them with preprocessor commands like #define, #include, etc. Armed with this, users could optionally provide header files of defines to standardize the naming of the OIDs and easily reuse the definitions across multiple scripts, and we can standardize the community's expectations about how text in a script gets changed to the raw OIDs. If we also added #if, #else, #then directives, scripts could also hide some of the variations between target devices' objects in their header files, improving the interoperability and reusability of their scripts. > > It would be extremely challenging for a non SNMPCONF WG member to > fully implement the PM MIB just by reading this document, let alone > getting two of them to create inter-operating implementations. > I think it will be difficult for SNMPCONF WG members to do so, basing it solely on reading the document as currently written. dbh ------_=_NextPart_001_01C1A7FD.CEE4A520 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Andy's review of draft-ietf-snmpconf-pm-09.txt

Comments inline

> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]=
>
> It's not really under-specified, but rather = just not well organized.
> The big areas for improvement:
>   - explain the whole before diving = into the details of the parts
>   - collect related information into = one place
>   - remove all forward references to = concepts, MIB objects, and terms
>   - make examples consistent and = correct, and use lots of them
>   - attempt the clarify the runtime = behavior and document one
>     suggested = implementation strategy of the runtime environment
>
These were also the cause of many of my comments. = I've been involved in the snmpconf effort, and had difficulty wading = through all the forward references and the little rules about = implementations throughout the document.

> >2) Andy comments repeatedly about strings = appearing in
> places where they "are not = allowed".  It appears that Andy
> missed (and therefore we need to emphasis = better) the fact
> that these strings are supposed to be processed = on the front
> end.  The fact that we are not mandating a = front end, but are
> describing all our examples as if there is a = smart front end
> does produce a tension (rather like the on in = (1) above) that
> should be addressed.  I actually muchly = prefer the use of the
> text strings, as if the examples used explicit = numeric OIDs I
> would have no idea what the examples were = doing.
>
> IMO, the WG is making a flawed assumption about = scripting, by
> requiring a front end to translate some parts = of the source code
> before loading the pmPolicyCodeTable. Humans = should be able to
> generate 100% of the source code without = additional tools.
> (That's why I put an OID Alias table in the SEE = MIB.)
>
> The examples should show the real ASCII-dotted = OID and the string
> version in a comment.  It is very = confusing to see all those
> verbose disclaimers about how the code really = doesn't look like
> this -- it's human nature to assume the authors = would only include
> valid examples of the programming language, and = base their own
> code on those examples. 

I have a concern that we are giving examples that do = not reflect what the language actually supports.

I feel that the reason this is being done is that = nobody would be able to understand the scripts if the supported formats = were used everywhere. But we expect operators to write interoperable = scripts without the benefit of writing it with text names. If people = involved in SNMP as much as we are cannot make sense of a script = "snippet" if it is written with OIDs, imaging the state we = are forcing on an operator who needs to configure policies for a = complete router using complex scripts that contain only the raw OIDs = and raw parameters.

While I agree with Andy that it is undesirable to = force users to use an application to write meaningful scripts, I = suspect that many in this WG assume there will be a pre-processor = involved. We don't make that easy for users; do the expected = preprocessors contain hard-coded aliases for known OID equivalents?. =

If we expect operators to use a preprocessor why = don't we provide them with preprocessor commands like #define, = #include, etc. Armed with this, users could optionally provide header = files of defines to standardize the naming of the OIDs and easily reuse = the definitions across multiple scripts, and we can standardize the = community's  expectations about how text in a script gets changed = to the raw OIDs. If we also added #if, #else, #then directives, scripts = could also hide some of the variations between target devices' objects = in their header files, improving the interoperability and reusability = of their scripts.

>
> It would be extremely challenging for a non = SNMPCONF WG member to
> fully implement the PM MIB just by reading this = document, let alone
> getting two of them to create inter-operating = implementations.
>
I think it will be difficult for SNMPCONF WG members = to do so, basing it solely on reading the document as currently = written.

dbh

------_=_NextPart_001_01C1A7FD.CEE4A520-- From owner-snmpconf@seymour39.SNMP.COM Mon Jan 28 08:40:41 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24870 for ; Mon, 28 Jan 2002 08:40:41 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA25076 for snmpconf-outgoing; Mon, 28 Jan 2002 08:33:19 -0500 (EST) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0E5F6BB9@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf@snmp.com Subject: RE: review of draft-ietf-snmpconf-pm-09.txt Date: Mon, 28 Jan 2002 14:32:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com David, has cabletron submitted a statement to the iesg-secretary about that? If not, do you think you can motivate them to do so? Randy Presuhn actually did send a statement for BMC. It is available at: http://www.ietf.org/ipr.html or more specific: http://www.ietf.org/ietf/IPR/BMC-SNMPCONF.txt Thanks, Bert -----Original Message----- From: Harrington, David [mailto:dbh@enterasys.com] Sent: Monday, January 28, 2002 1:34 PM To: snmpconf@snmp. com (E-mail) Subject: review of draft-ietf-snmpconf-pm-09.txt Andy observed: "[pg 116, sec 17, Intellectual Property] I think different text is supposed to go here if the WG knows of any claims of patented IP pertaining to this work, and I believe BMC Software is making such a claim." Cabletron (Enterasys) also identified to the WG three patents it has which may pertain to this work. dbh