NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Randy Presuhn <rpresuhn@bmc.com>
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Bert Wijnen <bwijnen@lucent.com>
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
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
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. |
Mar 01 |
|
WG agreement on direction regarding mappings to / from other alarm frameworks |
Mar 01 |
|
Submit updated Script and Schedule MIBs for consideration as Draft Standard (or recycle at Proposed). |
Mar 01 |
|
Submit updated draft of Alarm MIB for IETF meeting |
Mar 01 |
|
decision on question of whether recycle the Log MIB. |
Jul 01 |
|
Submit updated draft of Alarm MIB for IETF meeting. |
Aug 01 |
|
WG last call on Alarm Management MIB. |
Sep 01 |
|
Alarm Management MIB delivered to IESG for consideration as a Proposed Standard. |
Oct 01 |
|
call for implementation experience and updatescall for implementation experience and updatescall for implementation experience and updates to the remote operations MIB. |
Oct 01 |
|
call for implementation experience and updates to the Event and Expression MIBs. |
· Definitions of Managed Objects for Scheduling Management Operations
· Definitions of Managed Objects for the Delegation of Management Scripts
RFC |
Status |
Title |
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 |
51st IETF (London) DISMAN WG, 06/08/2001, 0900 GMT
Meeting chaired by Randy Presuhn
Reported by: Lauren Heintz
Note: Search for "***" for action items.
Randy opened with agenda bashing. David Perkins requested to add a review of the notification log MIB to the agenda, and this was accepted.
Randy gave status updates for various MIBs: the script MIB is now in the hands of the RFC editor the schedule MIB is in IETF last call (until August 28th) there may be an inconsistency between the expression and event MIBs; the remote OPs, event and notification-log MIBs are proposed stds; the noitification-log MIB apparently has one object that needs deprecation.
The latest Alarm MIB draft is now at v02, and incorporates the ITU-Alarm MIB.
The Condition MIB, v01, is now being written and is slated to replace older condition, Alarm and ARC MIBs. An issue was raised that only published drafts should be discussed, but the group decided to allow discussion of the forthcoming Condition MIB.
David Perkins suggested that the Alarm MIB may not have fully considered Telcordia requirements and asks that Telcordia Alarm models and terminology be considered/adopted. Kam suggested ITU is a superset of Telcordia.
Bert asked David to research Telcordia documents and perhaps coordinate a "loan" of such to the IETF DISMAN WG.
***David agreed to take an action item on this.
Sharon presented the ITU Active Alarm MIB: overview, changes since Minneapolis, Issues.
The v02 draft now includes these changes:
- architecture goals section
- alignment with condition and ARC
- added optional generic alarm notifications
- made alarm state transitions to be more flexible
- combined drafts. though MIBs remain in separate MODULEs
- added more examples
- created ITU IANA TC
Active alarm MIB is independant of condition MIB; may need more work to decouple them more
May want IANA to control certain TCs (e.g. probable cause). As a rule of thumb, it was stated that IANA should control TCs that change over time.
It was stated there was no need to create a new ID for TCs not destined for IANA. Instead, they should be put in the Active Alarm MIB document. This caused some debate: Dan Rom' cautioned about linking IDs and the need to avoid cyclical dependencies, Sharon wanted stand-alone TC MIB within the Alarm ID, Mike Ayers does not want too many IDs. It was decided that consolidation was a good short term strategery and that things could change a bit later on if the situation warranted it.
Dave Shields - Alarm Model State in example 6 incorrectly uses ITU Severity states, which are unordered.
David Perkins raised new issues about terminology, incorrect usage of SHOULD/MUST/etc.
***David should send these detailed issues to the list.
*** Randy promised/volunteered that the editors would track all raised issues.
*** Randy took an action item to update the charter with the revised/consolidated MIB lists.
David Perkins raised concern whether the ActiveAlarmTable could be used by a manager. He is mainly concerned about the use of TimeFilter, which he contends is incorrectly used in this case. Dan Rom' indicated TimeFilter was added as an index to help managers efficiently determine whether a specific Alarm had been cleared or not. This is because another mechanism does not exist in the MIB to determine what alarms had been cleared since a prior manager/agent alarm sync. No objections were heard to a proposed requirement to have an efficient mechanism to determine cleared alarms.
Juergen adds as a clarification to the above issue: I think it is worthwhile to add a note here that TimeFilters do not help to address the requirement. TimeFilters can help to identify the rows that changed since the last poll - they do not help to identify the rows that got added/deleted since the last poll.
A debate ensued about whether or not alarms need to be reportable without notifications. Randy indicated that for implementations that chose to use the AgentX notify PDU, notifications would result.
A question was raised about whether the current mechanism for matching notifications to conditions is sufficient.
***Sharon took an action item to provide audit results to the list for further discussion.
Kam discussed the new, as of yet unpublished, condition MIB.
It was pointed out that TimeInterval has potential issues in distributed architectures if provided as a scalar instead of within a table.
Sharon raised an issue about inconsistent indexing in the v00 draft MIB version and suggested ARC and alarm MIBs should use consistent indices that are also conducive to the entity MIB.
Mike raised concerns about whether it is proper to tie alarms and entities together, and Dale suggested that entPhysicalIndex is very appropriate to use.
*** Mike took an action item to raise a thread on the list about the mechanism to identify alarm sources and whether the entity MIB is useful. It was suggested we need to refrain from defining custom alarm source defs and to perhaps instead use OIDs to allow generic source IDs.
*** Kam took an action item to bring discussion to list regarding notification-log MIB security issues. NOTE: Kam has since indicated he is not the POC for this action item.
The group was asked whether there were suggestions for further script MIB work within DISMAN WG? No respone.
Charter updates were considered and it was decided that the March 01 date for recycling the log-mib needed more thought. It was also suggested that the August01 milestone (alarm MIB) needed a new date.
Dan Rom' suggested a last-call was possible for the Alarm mgmt MIB for a late December or early January.
*** Randy took an action item to get Bert suitably sauced to get this accepted.
It was stated that the current December charter milestones were still feasible as of now.
NOTE: I see no December milestone on the charter (which was last updated 9 August -- today). Perhaps we were instead talking about the "proposed" December milestones above?
*** Mike took an action item to discuss arch' issues about justification for differences between alarm and condition MIBs.
*** Kam and Sharon took an action item to ensure docs are clearer about the distinction and also the complimentary nature of alarm and condition MIB.
Alarm MIB (Generic & ITU)
Alarm Reporting Control
Condition MIB