Hi Bill,
I withdraw this proposal - this is for WIMS/1.1, if that ever
happens - expanding the scope of WIMS requirements to actually
harmonize with existing/deployed network management systems
isn't practical.
The standard network management behemoths (colorful phrase!)
have toolkits for 'access methods' - the protocol on the
outside of those access methods need not be SNMP or WBEM.
By standardizing the interface from a WIMS Proxy Agent to
an access method as WIMS protocol, the work is offloaded
from the WIMS Proxy Agent to the one or more WIMS Proxy
Managers in access methods.
If HP OpenView folks were still actively participating in
the WIMS working group, this would have seemed important.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
-----Original Message-----
From: A. Lynne Wagner [mailto:LynneWagner@comcast.net]
Sent: Monday, February 21, 2005 6:35 PM
To: 'McDonald, Ira'; wims@pwg.org
Subject: RE: WIMS> Proposal for WIMS Proxy Interfaces
Ira,
Good point. However, there are a significant number of sites that do accept
an integrated WIMS/SNMP proxy independent of a more involved management
system that may or may not be in place. I agree that having a well
established interface to standard network management behemoths would be
advantageous. But would the interface be the same for the various flavors?
Or would all systems accept an SNMP structured query (for example)? The
general idea of the proxy is that the proxy agent implements the schedule
and alert sense functions, but relies upon some other protocol to get or
send actual management information to the end-point managed entities. A
statement as to how this information may be obtained via SNMP polls or alert
setups may be useful in explaining how a WIMS/SNMP proxy works, and may be a
justifiable effort if it could act as the proxy interface you reference. But
I would suggest postponing any more ambitious address of this interface
until there is both an indication of need and an understanding of what would
be necessary make this interface compatible with likely systems.
There are a significant number of people on this list. We would certainly be
interested in whether this additional interface pair is seen as a
requirement (and indeed, any other comments on WIMS objectives and current
definition).
Bill Wagner
-----Original Message-----
From: owner-wims@pwg.org [mailto:owner-wims@pwg.org] On Behalf Of McDonald,
Ira
Sent: Monday, February 21, 2005 4:55 PM
To: 'A. Lynne Wagner'; wims@pwg.org
Subject: RE: WIMS> Proposal for WIMS Proxy Interfaces
Hi Bill,
In actual customer deployments these are NOT 'internal
interfaces'. In a typical large enterprise environment,
a WIMS Proxy Agent might be forwarding to/relaying from
existing system management applications using IETF SNMP,
OASIS WSDM, and DMTF WBEM.
Major system management applications are ALWAYS deployed
on dedicated systems with extremely high security. And
single-system license cost of HP OmniView, CA Unicenter,
and IBM Tivoli all start at US $50,000 and ascend rapidly
to US $250,000 for a larger number of managed entities.
All of these commercial system management stations have
toolkits for writing "access methods" to/from other
management protocols, but they ALL require that the
"access method" runs on the same platform as the deployed
system management station (to avoid compromised security).
Even if a printer vendor was willing to spend the money
to imbed multiple native management protocols in a WIMS
Proxy Agent, no customer would be willing to deploy it.
So the remote WIMS Proxy Manager (on a different host
than the WIMS Proxy Agent) will be the dominant pattern.
If we leave these forwarding/relaying interfaces as an
exercise for the implementor, we make WIMS deployment
much less likely.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
-----Original Message-----
From: A. Lynne Wagner [mailto:LynneWagner@comcast.net]
Sent: Monday, February 21, 2005 2:58 PM
To: 'McDonald, Ira'; wims@pwg.org
Subject: RE: WIMS> Proposal for WIMS Proxy Interfaces
Ira,
I sketched out what I understand you to be referring to. Assuming that I
understand correctly, I have been regarding these as "internal interfaces",
even if it were seen necessary to remote the proxy agent from the proxy
manager (which, to me, seems unlikely). That is, I would regard these
interfaces as implementation dependent and not necessary for WIMS to
specify, aside from the implicit requirement that they preserve as much of
the WIMS protocol information as possible. I also suggest that the form of
this interface would probably be different in the case of a WINS-to-SNMP
proxy versus a WIMS-to-WIMS proxy or a WIMS-to-HTTP Web page proxy, etc.
Bill Wagner
-----Original Message-----
From: owner-wims@pwg.org [mailto:owner-wims@pwg.org] On Behalf Of McDonald,
Ira
Sent: Monday, February 21, 2005 11:43 AM
To: 'wims@pwg.org'
Subject: WIMS> Proposal for WIMS Proxy Interfaces
Hi folks, Monday (21 February 2005)
After recent work on the WIMS Object Model, I see a need for two more
WIMS interfaces:
(1) Proxy Agent Interface - operation requests forwarded by a WIMS Proxy
Agent to a (local or remote) subordinate WIMS Proxy Manager and
subsequently delivered to subordinate Agent(s) registered with that
Proxy Manager
(2) Proxy Manager Interface - operation requests relayed by a WIMS Proxy
Manager to a (local or remote) superior WIMS Proxy Agent, based on
operation requests received from subordinate Agent(s) registered
with that Proxy Manager
Comments?
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
------------------------------------------------------------------------
There are two possible network topologies for a WIMS Proxy:
Integrated WIMS Proxy
{DomainA} {............DomainB............}
*-------* *-------* *-------* *-------*
| Top | | Proxy | | Proxy | | End |
|Manager| | Agent | |Manager| | Agent |
*-------* *-------* *-------* *-------*
(HostA) (......HostB......) (HostC)
Distributed WIMS Proxy
{DomainA} {............DomainB............}
*-------* *-------* *-------* *-------*
| Top | | Proxy | | Proxy | | End |
|Manager| | Agent | |Manager| | Agent |
*-------* *-------* *-------* *-------*
(HostA) (HostB) (HostC) (HostD)
Notes:
(1) If DomainA and DomainB are different, then this is fleet management
and firewalls constrain the origin of connections.
(2) If DomainA and DomainB are the same, this is enterprise management.
(3) In all cases, Proxy Agent, Proxy Manager, and End Agent MUST be in
the same domain for any practical implementation.
(4) In the 'Integrated WIMS Proxy' case, Proxy Agent to Proxy Manager
communications MAY be proprietary.
(5) In the 'Distributed WIMS Proxy' case, Proxy Agent to Proxy Manager
communications MUST be standardized (so these new interfaces should
be CONDITIONALLY MANDATORY to support).
(6) These topologies are recursive, that is, the End Agent may in fact
be a Proxy Agent with further subordinate Proxy Managers.
------------------------------------------------------------------------
Proxy Agent Interface operations:
(1) ForwardAction
- forwarded ExecuteAction received from a superior WIMS Manager
- triggered Action in a current Schedule on the Proxy Agent
(2) ForwardSchedule
- forwarded SetSchedule received from a superior WIMS Manager and
possibly decomposed by the Proxy Agent
------------------------------------------------------------------------
Proxy Manager Interface operations:
(1) RegisterForProxy
- registers Proxy Manager with superior Proxy Agent
based on prior configuration (NOT dynamic discovery)
(2) UnregisterForProxy
- unregisters Proxy Manager with superior Proxy Agent
(3) RelayRegister
- relayed RegisterForManagement received from a subordinate WIMS
Agent and possibly aggregated or delayed by the Proxy Manager
(4) RelayUnregister
- relayed UnregisterForManagement received from a subordinate WIMS
Agent and possibly aggregated or delayed by the Proxy Manager
(5) RelayAlerts
- relayed SendAlerts received from a subordinate WIMS Agent
and possibly aggregated or delayed by the Proxy Manager
(6) RelayReports
- relayed SendReports received from a subordinate WIMS Agent
and possibly aggregated or delayed by the Proxy Manager
(7) RelayGetSchedule
- relayed GetSchedule received from a subordinate WIMS Agent
------------------------------------------------------------------------
Example Sequences of Operations:
*-------* *-------* *-------* *-------*
| Top | | Proxy | | Proxy | | End |
|Manager| | Agent | |Manager| | Agent |
*-------* *-------* *-------* *-------*
RegisterForProxy
<-----------/
RegisterForProxy.response
\----------->
*-------* *-------* *-------* *-------*
| Top | | Proxy | | Proxy | | End |
|Manager| | Agent | |Manager| | Agent |
*-------* *-------* *-------* *-------*
RegisterForManagement
<-----------/
RelayRegister
<-----------/
RegisterForManagement
<-----------/
RegisterForManagement.response
\----------->
RelayRegister.response
\----------->
RegisterForManagement.response
\----------->
*-------* *-------* *-------* *-------*
| Top | | Proxy | | Proxy | | End |
|Manager| | Agent | |Manager| | Agent |
*-------* *-------* *-------* *-------*
ExecuteAction
\----------->
ForwardAction
\----------->
ExecuteAction
\----------->
ExecuteAction.response
<-----------/
ForwardAction.response
<-----------/
ExecuteAction.response
<-----------/
*-------* *-------* *-------* *-------*
| Top | | Proxy | | Proxy | | End |
|Manager| | Agent | |Manager| | Agent |
*-------* *-------* *-------* *-------*
GetSchedule
<-----------/
RelayGetSchedule
<-----------/
GetSchedule
<-----------/
GetSchedule.response
\----------->
RelayGetSchedule.response
\----------->
GetSchedule.response
\----------->
------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Tue Feb 22 2005 - 12:02:33 EST