[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Review of draft-ietf-snmpconf-bcp-07

Title: 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
                   "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-
               ::= { 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]

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/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