Current Meeting Report
Slides


2.4.3 Distributed Management (disman)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 06/24/2002

Chair(s):
Randy Presuhn <rpresuhn@bmc.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists:
General Discussion: disman@dorothy.bmc.com
To Subscribe: disman-request@dorothy.bmc.com
In Body: subscribe disman your_email_address
Archive: ftp://amethyst.bmc.com/pub/disman/archives
Description of Working Group:
The Distributed Management Working Group is chartered to define an initial set of managed objects for specific distributed network management applications which can be consistently developed and deployed. A distributed network manager is an applicaton that acts in a manager role to perform management functions and in an agent role so that it can be remotely controlled and observed.

Distributed network management is widely recognized as a requirement for dealing with today's growing internets. A manager application is a good candidate for distribution if it requires minimal user interaction, it would potentially consume a significant amount of network resources due to frequent polling or large data retrieval, or it requires close association with the device(s) being managed.

The working group will limit its work to distributed network management applications where the main communication mechanism for monitoring and control is SNMP. Future work (and other working groups) may be chartered to investigate other distribution techniques such as CORBA or HTTP. The objects defined by the working group will be consistent with the SNMP architecture defined in RFC 2571. The working group will especially keep security considerations in mind when defining the interface to distributed management.

The working group will complete these tasks:

Define a Scheduling MIB

Define a Script MIB

Define a Remote Operations MIB

Define an Expression and Event MIB to support Threshold Monitoring

Define a Notification Log MIB

Define an Alarm MIB

The working group will consider existing definitions, including:

o the RMON working group's work in this area

o the Application MIB (RFC 2564), SysAppl MIB (RFC 2287) and related standards.

The work on the Alarm MIB will take into consideration existing standards and practices, such as ITU-T X.733. Whether any mappings to these other standards appear in the Alarm MIB or in separate documents will be decided by the WG. The WG will actively seek participation from ITU participants to make ensure that the ITU work is correctly understood.

It is recognized that the scope of this working group is narrow relative to the potential in the area of distributed network management. This is intentional in order to increase the likelihood of producing useful, quality specifications in a timely manner. However, we will keep in mind and account for potential related or future work when developing the framework including:

o Event and alarm logging and distribution

o Historical data collection/summarization

o Topology discovery

Goals and Milestones:
Done  Post Internet-Draft for Threshold Monitoring MIB.
Done  Meet at the Montreal IETF meeting to discuss charter and review the Threshold Monitoring MIB Internet-Draft.
Done  Post Internet-Draft for Framework document.
Done  Post Internet-Draft for Script MIB.
Done  Submit final version of Threshold Monitor MIB Internet-Draft for consideration as a Proposed Standard. Submit updated versions of Internet-Drafts for Script MIB.
Done  Meet at the IETF meeting to discuss Internet-Drafts and issues that come up on the mailing list.
Done  Submit final versions of Internet-Drafts for Script MIB and Schedule MIB document for consideration as Proposed Standards.
Done  Agree on charter revisions for future work.
Done  Submit final versions of Internet-Drafts for Expression, Event and Notification MIB documents for consideration as Proposed Standards.
Done  Submit final version of Internet-Draft for Remote Ping, Traceroute, and Lookup Operations Using SMIv2
Done  Meeting in Oslo to discuss implementation and deployment experience with Schedule and Script mibs, identify any updates needed to these documents.
Done  WG agreement on direction regarding mappings to / from other alarm frameworks
Done  Submit updated Script and Schedule MIBs for consideration as Draft Standard (or recycle at Proposed).
Done  Submit updated draft of Alarm MIB for IETF meeting
Done  decision on question of whether recycle the Log MIB.
Done  Submit updated draft of Alarm MIB for IETF meeting.
Done  call for implementation experience and updates to the remote operations MIB.
Done  call for implementation experience and updates to the Event and Expression MIBs.
DEC 01  WG last call on Alarm Management MIB.
JAN 02  Alarm Management MIB delivered to IESG for consideration as a Proposed Standard.
Internet-Drafts:
  • - draft-ietf-disman-alarm-mib-07.txt
  • - draft-ietf-disman-conditionmib-02.txt
  • - draft-ietf-disman-event-mib-v2-00.txt
  • - draft-ietf-disman-express-mib-v2-00.txt
    • Request For Comments:
    RFCStatusTitle
    RFC2591 PS Definitions of Managed Objects for Scheduling Management Operations
    RFC2592 PS Definitions of Managed Objects for the Delegation of Management Scripts
    RFC2925 PS Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations
    RFC2982 PS Distributed Management Expression MIB
    RFC2981 PS Event MIB
    RFC3014 PS Notification Log MIB
    RFC3165 PS Definitions of Managed Objects for the Delegation of Management Scripts
    RFC3231 PS Definitions of Managed Objects for Scheduling Management Operations

    Current Meeting Report

     TUESDAY--------

    DISMAN WG Meeting minutes
    Date : 07/16/2002
    Time : 1545-1645
    Room Number : 304
    Reported by : Niraj Gopal (niraj@cisco.com)

    Chair Presentation:

    The chair mentioned that INTAP/OSMIC (http://www.intap.or.jp) is working on CIM/XML over SOAP for Alarms and that might be relevant for us. But no specific action is needed. XMLCONF might have some impact on us e.g. Juniper scheme does not send events thru XML.

    Condition MIB Prsentation:

    Action Item - Bert to resolve Boiler plate references for rfc1155, 1215, 1157, 2571 to informative/normative. Especially becasue SNMPv1 status is now historic and should be informative.

    Action Item - For security section, Kam to list the objects that are read-create or read-write and if they contain any privacy information.

    There was a discussion regarding referential integrity problem in one of the tables in this MIB. That MIB table uses a fully qualified Object Identifier of a resource (MIB Varable in another table) as one of its indices. But the value of that resource ID can change across reboots thereby causing this MIB table index to point to some other value, if the table is persisted. In addition, VACM configuration for such resource IDs can be problematic.

    It was asked if it would be adequate to say in the Security Considerations section that resources with unstable indices (non-persistent) can have problems. Bert pointed out that we need a separate doc as this a generic problem. Randy pointed out that ADSL profiles handle it thru description and that it is a known limitation of VACM.

    Action Item - A BCP might be needed for this general referential integrity problem.

    Shall we add a storage type to this table or save all entries? David Perkins pointed out that for CLI you cannot say if a particular instance be saved while others are not but it could be SNMP specific. Bert mentioned that either storage type or all entries saved is fine but it should be the same as we have been doing.

    Action Item - Kam to raise this question on mailing list if all entries should be persistent or only some.

    Action Item - Kam to define a IANAItuProbableCauseOrZero TC in this MIB with Unsigned32 syntax that can take any value of IANAItuProbableCause or 0. IANA should also be informed not to assign 0, in future, for IANAItuProbableCause.

    Bert pointed out that it could have a 0 value and 0 in Index is not good. Randy suggested that it is ok for this case.

    Rest of the presentation to be finished on Thursday.


    THURSDAY--------

    DISMAN WG Meeting minutes
    Date : 07/16/2002
    Time : 1545-1645
    Room Number : 304
    Reported by : Niraj Gopal (niraj@cisco.com)

    Chair Presentation:

    The chair mentioned that INTAP/OSMIC (http://www.intap.or.jp) is working on CIM/XML over SOAP for Alarms and that might be relevant for us. But no specific action is needed.

    XMLCONF might have some impact on us e.g. Juniper scheme does not send events thru XML.

    Condition MIB Prsentation:

    Action Item - Bert to resolve Boiler plate references for rfc1155, 1215, 1157, 2571 to informative/normative. Especially becasue SNMPv1 status may be going historic and should be informative.

    Action Item - For security section, Kam to list the objects that are read-create or read-write and if they contain any privacy information.

    There was a discussion regarding referential integrity problem in one of the tables in this MIB. That MIB table uses a fully qualified Object Identifier of a resource (MIB Varable in another table) as one of its indices. But the value of that resource ID can change across reboots thereby causing this MIB table index to point to some other value, if the table is persisted. In addition, VACM configuration for such resource IDs can be problematic.

    It was asked if it would be adequate to say in the Security Considerations section that resources with unstable indices (non-persistent) can have problems. Bert pointed out that we need a separate doc as this a generic problem. Randy pointed out that ADSL profiles handle it thru description and that it is a known limitation of VACM.

    Action Item - A BCP might be needed for this general referential integrity problem.

    Shall we add a storage type to this table or save all entries? David Perkins pointed out that for CLI you cannot say if a particular instance be saved while others are not but it could be SNMP specific. Bert mentioned that either storage type or all entries saved is fine but it should be the same as we have been doing.

    Action Item - Kam to raise this question on mailing list if all entries should be persistent or only some.

    Action Item - Kam to define a IANAItuProbableCauseOrZero TC in this MIB with Unsigned32 syntax that can take any value of IANAItuProbableCause or 0. IANA should also be informed not to assign 0, in future, for IANAItuProbableCause.

    Bert pointed out that it could have a 0 value and 0 in Index is not good. Randy suggested that it is ok for this case.

    Rest of the presentation to be finished on Thursday.



    Disman Thursday 3:30 18 July 2002

    Reported by Chris Elliott chelliot@cisco.com

    Alarm MIB

    Alarm 38: This issue needs to be clarified on the mailing list.

    Alarm 42: Sharon gets to do what she wants with this and will post her decision for comments on the mailing list.

    Alarm n+2: Reserve 0 in TC and point IANA to this TC so they know to not allocate 0.


    Clustering and Replication

    No consensus on if this would be useful.

    Needs further discussion on mailing list.


    MIB table modification tracking MIB

    Meeting seemed to have a fair amount of interest in developing this MIB.

    Should it include all objects in table, exclude all counters, or exclude all objects by default?

    Needs further discussion on mailing list


    Distributed Management Apps.

    No consensus whether the IETF is the appropriate org for this or whether SNMP has a role here.

    No action required. Continued discussion should be on ops-nm mailing list.


    Charter Updates

    Have two target dates overdue?

    Alarm MIB will be updated and go WG last call August. ARC MIB update next week and will go WG last call then.

    Can disman go dormant?

    Consensus of meeting (not list) was that there is still interesting things to work on.

    Slides

    Agenda
    Alarm MIB
    Condition MIB Alarm Report Control
    An Architecture for Clustering and Replication
    Table Modifications Tracking MIB Proposal
    Distributed Management Apps