DISMAN Working Group
Bruce Hale
Hello,
Could someone please send me the email address for subscribing to the
DISMAN working group mail list?
Thanks,
Bruce Hale
*********************************************************
* Bruce Hale E-Systems, Inc. *
* System Architect Garland Div. *
* Email: beh...@esy.com P.O. Box 660023 *
* Phone: 214-205-8955 M/S MC-35500 *
* Fax: 214-205-6144 Dallas, TX 75266 *
*********************************************************
On Wed Jun 12 10:45:18 1996 Bob Natale wrote:
>> From: Maria Greene <gre...@nexen.com>
>> Date: Wed, 12 Jun 1996 09:08:36 -0400
>
>Hi Maria,
>
>> For those of you who are not on the ietf-announce mailing list,
>> the IESG has officially chartered the DISMAN working group!
>
>Thanks for ushering this through the process...your level of
>expertise and participation as demonstrated in many other
>IETF and industry net management efforts bodes very well for
>the success of the disman wg.
>
>I do have a few comments/questions about the charter/work
>plan (below)...and I apologize for the cross-post to both
>the snmp and disman lists...it appeared from your majordomo
>last night that people are still in the early stages of
>signing up to the disman list, so I thought it best to
>direct this to the snmp list too...if you would like follow-ups
>to go the disman list only, please let us know.
>
>1. I note that you plan to use some of the meeting time in
>Montreal to discuss the scope of the wg...good...but the
>most important observation I have upon reading the charter
>is that the Framework effort should come first...before we
>start defining specifics, such as the Threshold MIB. I
>believe that the following text from the charter supports
>this view (in spite of the ordering in the excerpt):
>
>> The Distributed Management Working Group is chartered to define an
>> initial set of managed objects for specific distributed network
>> management applications and a framework in which these applications
>> and others can be consistently developed and deployed.
>
>2. Also:
>
>> The working group will complete these tasks:
>>
>> o Define a Threshold Monitoring MIB
>> o Define a Script MIB
>> o Define a Distribution Management Framework and MIB
> ^^^^^^^^^^^^
>I think we should refer to that as a *Distributed* Management
>Framework.
>
>3. > Goals and Milestones
>
>As my #1 comment indicates, I think the milestone schedule
>should be revised to incorporate completing the Framework
>document(s) first.
>
>4. Also (a general note the NM Area Director and Directorate),
>while I know that it is necessary (for a lot of reasons) to
>schedule aggerssively, I feel that given the high level of
>cross-participation in related working groups (which many in
>this area are, I believe) consideration of other wg charter
>schedules should be included in the schedule planning for a
>new group. Perhaps this was done in this case and the schedule
>shown is the result...but I am a bit fearful of further diluting
>on-going efforts on the entmib, applmib, rmon2, and agentx wgs
>(among others IETF and industry net mgmt standardization
>efforts) with this new workload.
>
>(Please note that I am 100% in favor of the disman effort...
>long overdue and a critical interest area for me personally
>and my company's product plans.)
>
>Ok, enough whining from me!
>
>Cordially,
>
>BobN
>------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------
>Bob Natale | ACE*COMM | 301-258-9850 [v]
>Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f]
>nat...@acec.com | Gaithersburg MD 20877 | http://www.acec.com
>------- NetPlus (r) "FCAPS" Telemanagement Applications --------
>
>
>
>
Bob Natale
Maria Greene
For those of you who are not on the ietf-announce mailing list, the
IESG has officially chartered the DISMAN working group! The charter is
included below. Please subscribe to the working group mailing list
for discussion about the charter or anything else related to the
working group.
The meeting slots in Montreal are:
Monday, June 24, 9:30 - 11:30
Tuesday, June 25, 1:00 - 3:00
I will be posting the agenda to the disman mailing list. Note that the
agenda will include time to discuss the working group's scope and
deliverables (with an eye toward fine-tuning them based on working
group interest) and will include slots for prepared presentations.
________________________________________________________________________
Maria N. Greene gre...@nexen.com
Ascom Nexion 289 Great Rd., Acton MA 01720 USA +1 508 266-4570
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Distributed Management (disman) Charter
Chair(s)
o Maria Greene <gre...@nexen.com>
Network Management Area Director(s)
o Deirdre Kostick <kos...@qsun.att.com>
Mailing List Information
o General Discussion: dis...@nexen.com
o To Subscribe: majo...@nexen.com
o In Body: subscribe disman your_email_address
o Archive: TBD
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 and a framework in which these applications
and others can be consistently developed and deployed. A distributed
network manager is an application 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 communication mechanism used between
managers (or the components of the management application) 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
framework. The working group will especially keep security
considerations in mind when defining the interface to distributed
management.
The working group will complete these tasks:
o Define a Threshold Monitoring MIB
o Define a Script MIB
o Define a Distribution Management Framework and MIB
This last MIB is required in order to keep distributed managers from
adding to the management problem. This MIB will allow distributed
managers of many types to be controlled in a consistent way including
controlling their "management domain" (the set of devices upon which
they act), the relationships between the management applications or
components, and to some extent the scheduling of their operation.
The working group will consider existing definitions, including:
o RFC1451, The Manager to Manager MIB which was being considered by
the SNMPv2 working group
o the RMON working group's work in this area
o the SNMP Mid-Level-Manager MIB which is now an expired Internet
Draft
o the work of the Application MIB working group
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
Hold BOF at Danvers IETF meeting.
May 96
Post Internet-Draft for Threshold Monitoring MIB.
Jun 96
Meet at the Montreal IETF meeting to discuss charter and review the
Threshold Monitoring MIB Internet-Draft.
Jul 96
Post Internet-Draft for Framework document.
Aug 96
Post Internet-Draft for Script MIB.
Sep 96
Meet at the IETF meeting to discuss Internet-Drafts and issues that
come up on the mailing list.
Nov 96
Submit final version of Threshold Monitor MIB Internet-Draft for
consideration as a Proposed Standard.
Submit updated versions of Internet-Drafts for Script MIB and the
Framework document.
Dec 96
Meet at the IETF meeting to discuss Internet-Drafts and issues that
come up on the mailing list.
Feb 97
Submit final versions of Internet-Drafts for Script MIB and
Framework document for consideration as Proposed Standards.
No Current Internet-Drafts
Request for Comments
RFC1451 -- The Manager to Manager Management Information Base
(historic)
David Harrington
According to Maria Greene:
>
> Maria> The working group will complete these tasks:
> Maria>
> Maria> o Define a Threshold Monitoring MIB
> Maria> o Define a Script MIB
> Maria> o Define a Distribution Management Framework and MIB
> Bob> ^^^^^^^^^^^^
> Bob> I think we should refer to that as a *Distributed* Management
> Bob> Framework.
>
> Yes, that's a typo, but it emphasizes that point that we have to be
> able to manage the distribution of the management function itself. If
> you're a (human) manager and you've got pieces of your distributed
> management application scattered through your network, it's going to
> be very important to know where they are, what their status is, to be
> able to "program" them collectively, etc. Otherwise, the management
> applications just become part of the problem.
>
I was happy to see "Distribution Management Framework" rather than
"Distributed Management Framework" in the charter, since there are
different aspects of distributing management, and the BOF centered
on distributing functionality via scripts.
Another aspect of distributing management important to customers is the ability
to share data between peer or hierarchical management platforms within an
enterprise, both homogenous and heterogenous platforms. I consider this
sharing of management responsibilities to be distributed management. I think
the Threshold MIB, the successor to the manager-to-manager MIB, falls under
the purview of distributed management.
A protocol to enable the distribution of scripts among hierarchical entities
seems more aptly described as network management distribution management or
script-distribution management that happens to be used for network management
scripts.
I would like to see the DISMAN WG address *both* a protocol for sharing of
data between distributed peer/hierarchical managers and a protocol for
distributing functionality between hierarchical distributed managers.
If the WG can't handle both, they should label script-passing as distribution
management to differentiate it from distributed management.
--
-----------------------------------------------------
#include <std.disclaimer>
David Harrington d...@ctron.com
Spectrum Network Management Platform Protocols Group
Cabletron Systems Inc.
-----------------------------------------------------
Maria Greene
>>>>> On Wed, 12 Jun 1996 10:44:26 -0400, Bob Natale <nat...@acec.com> said:
> From: Maria Greene <gre...@nexen.com>
> Date: Wed, 12 Jun 1996 09:08:36 -0400
Bob> Hi Maria,
Hi, Bob.
> For those of you who are not on the ietf-announce mailing list,
> the IESG has officially chartered the DISMAN working group!
Bob> Thanks for ushering this through the process...your level of
Bob> expertise and participation as demonstrated in many other
Bob> IETF and industry net management efforts bodes very well for
Bob> the success of the disman wg.
You are too kind.
Bob> I do have a few comments/questions about the charter/work
Bob> plan (below)...and I apologize for the cross-post to both
Bob> the snmp and disman lists...it appeared from your majordomo
Bob> last night that people are still in the early stages of
Bob> signing up to the disman list, so I thought it best to
Bob> direct this to the snmp list too...if you would like follow-ups
Bob> to go the disman list only, please let us know.
Subscribe requests are still coming in at a steady pace. I will
cross-post for now.
Bob> 1. I note that you plan to use some of the meeting time in
Bob> Montreal to discuss the scope of the wg...good...but the
Bob> most important observation I have upon reading the charter
Bob> is that the Framework effort should come first...before we
Bob> start defining specifics, such as the Threshold MIB. I
Bob> believe that the following text from the charter supports
Bob> this view (in spite of the ordering in the excerpt):
> The Distributed Management Working Group is chartered to define an
> initial set of managed objects for specific distributed network
> management applications and a framework in which these applications
> and others can be consistently developed and deployed.
I agree with you on the importance of reaching agreement on the
Framework. We must define an architecture that is scalable,
implementable, and deployable if any of this is going to fly.
Bob> 2. Also:
> The working group will complete these tasks:
>
> o Define a Threshold Monitoring MIB
> o Define a Script MIB
> o Define a Distribution Management Framework and MIB
Bob> ^^^^^^^^^^^^
Bob> I think we should refer to that as a *Distributed* Management
Bob> Framework.
Yes, that's a typo, but it emphasizes that point that we have to be
able to manage the distribution of the management function itself. If
you're a (human) manager and you've got pieces of your distributed
management application scattered through your network, it's going to
be very important to know where they are, what their status is, to be
able to "program" them collectively, etc. Otherwise, the management
applications just become part of the problem.
Bob> 3. > Goals and Milestones
Bob> As my #1 comment indicates, I think the milestone schedule
Bob> should be revised to incorporate completing the Framework
Bob> document(s) first.
This is a good suggestion.
Bob> 4. Also (a general note the NM Area Director and Directorate),
Bob> while I know that it is necessary (for a lot of reasons) to
Bob> schedule aggerssively, I feel that given the high level of
Bob> cross-participation in related working groups (which many in
Bob> this area are, I believe) consideration of other wg charter
Bob> schedules should be included in the schedule planning for a
Bob> new group. Perhaps this was done in this case and the schedule
Bob> shown is the result...but I am a bit fearful of further diluting
Bob> on-going efforts on the entmib, applmib, rmon2, and agentx wgs
Bob> (among others IETF and industry net mgmt standardization
Bob> efforts) with this new workload.
Scheduling is always difficult, whether it's a large project in a
company or in an IETF working group. In Montreal I did consult with
additional working group chairs, with Deirdre, and with the document
editors and maybe we can adjust the dates if necessary.
Bob> (Please note that I am 100% in favor of the disman effort...
Bob> long overdue and a critical interest area for me personally
Bob> and my company's product plans.)
Excellent.
Bob> Ok, enough whining from me!
Bob> Cordially,
Bob> BobN
Bob> ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------
Bob> Bob Natale | ACE*COMM | 301-258-9850 [v]
Bob> Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f]
Bob> nat...@acec.com | Gaithersburg MD 20877 | http://www.acec.com
Bob> ------- NetPlus (r) "FCAPS" Telemanagement Applications --------
Maria
David Harrington
According to Randy Presuhn:
>
> > I would like to see the DISMAN WG address *both* a protocol for sharing of
> > data between distributed peer/hierarchical managers and a protocol for
> > distributing functionality between hierarchical distributed managers.
>
> protocols would be necessary to meet the requirements. It'll probably
> become clearer when we get down to detailed functional requirements.
>
Whoops! I forgot where I was. I meant protocol in the general sense of
agreed-to behaviors, etc., not in the sense of technical specification of
message formats, etc.
> I prefer a slightly different alignment of terms:
>
> - distribution management is an aspect of software / application
> management, ...
>
I agree that "distribution management" is a term used to describe a larger
management concept, and should be avoided.
If the DISMAN WG will focus on delegation of functionality, as the BOF
would indicate, I think "distributed management" should be avoided for the
same reason.
If the DISMAN WG addresses the larger picture, then "distributed management"
may be appropriate.
Randy Presuhn
Hi -
> From: David Harrington <d...@ctron.com>
> To: Multiple recipients of list <sn...@lists.psi.com>
> Subject: Re: DISMAN Working Group
..
> A protocol to enable the distribution of scripts among hierarchical entities
> seems more aptly described as network management distribution management or
> script-distribution management that happens to be used for network management
> scripts.
Script distribution management has two parts:
- management of the process
- delivery mechanisms
> I would like to see the DISMAN WG address *both* a protocol for sharing of
> data between distributed peer/hierarchical managers and a protocol for
> distributing functionality between hierarchical distributed managers.
I agree with the high-level requirement, though I'm not sure whether new
protocols would be necessary to meet the requirements. It'll probably
become clearer when we get down to detailed functional requirements.
> If the WG can't handle both, they should label script-passing as distribution
> management to differentiate it from distributed management.
I prefer a slightly different alignment of terms:
- script distribution mechanisms are whatever is
used to carry out the actual delivery of the script to its
place(s) of execution.
- distribution management is an aspect of software / application
management, concerned with the delivery and installation of
releases, upgrade, patches, and so on. ISO/IEC IS 10164-18
deals with some of these issues. This could include defining
relationships between MIB objects and specific delivery
mechanisms, such as FTP. I think this area, though important,
is probably broader than DISMAN.
- management delegation mechanisms include, among other things,
scripting. There are three distinct aspects of scripting as a
way of accomplishing management delegation:
- the definition of scripting languages, such as Java,
PSL, Telescript, Time-liner, and many others
- the management of script execution environments, as in
ISO/IEC DIS 10164-21. It is possible for the management
of a script execution environment to be fairly neutral
with respect to the set of languages supported by that
environment.
- mechanisms for the delivery of scripts to the place
of execution (potentially a special case of software
delivery and installation)
- two other aspects of management delegation mechanisms are the
representation and communication of aggregated information
between systems. The various metric objects in ISO/IEC 10164-11
and 10164-13 are helpful in illustrating some of the issues.
An important undercurrent in the discussions on the use of HTTP
in conjunction with management was the problem of ensuring that
the structure of the information (and its encoding) carried
by HTTP (or anything else) is something that a machine could
interpret (beyond simply displaying it). This gets into the
issues of SMI and abstract syntaxes.
-----------------------------------------------------------------------------
Randy Presuhn PEER Networks, a division of BMC Software, Inc.
Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130
Fax: +1 408 556-0735 San Jose, California 95129-3433
Email: randy_...@bmc.com USA
-----------------------------------------------------------------------------