WBMM> Differences

WBMM> Differences

Harry Lewis harryl at us.ibm.com
Fri Feb 7 15:28:56 EST 2003


Whether we define a "replacement for MIBs" as the result of "establishing 
a transport, protocol and format as part of the solution" ... or we do it 
because it is justifiable in itself... what's the difference?

I wold argue it IS justifiable for reasons I cited in an earlier post.. 
not the least of which is resolving some of the force fitting we did with 
the MIB (ex. MIB-II, hrMIB)... (ex. "magic decode ring"). 

Also, there are multiple models today (CIM, SNMP, NPAP etc.) which it 
would be good to consolidate

Also, this is an opportunity for the PWG to address MFP function which 
we've shied from for, probably, too long. 
---------------------------------------------- 
Harry Lewis 
IBM Printing Systems 
---------------------------------------------- 




"Wagner,William" <WWagner at NetSilicon.com>
02/07/2003 01:09 PM
 
        To:     Harry Lewis/Boulder/IBM at IBMUS, <wbmm at pwg.org>
        cc: 
        Subject:        RE: WBMM> Differences


Identifying and resolving differences, and coming to consensus is one of 
the main functions of a working group. So let see where the differences 
really lie.
 
I believe that scenarios add some specific to the general statements of 
scope. Harry has outlined one, or maybe two  here. I solicit from whomever 
has an opinion on this whatever other scenarios they would like addressed 
by this working group.
 
 I certainly agree that "management across the firewall" is the basis for 
multiple scenarios. To  me, the basic problem to be solved.
 
But is " standard protocol and NEW data model"  to be taken as an 
objective in itself , or is it part of the solution to the first?
 
Certainly, establishing a transport, a protocol, a format  all need to be 
defined as part of the solution. If there is a difference between me and 
my fellow officers, it is that I do not agree that establishing a 
replacement for MIBs (as has been cited earlier) is justifiable as an 
objective in itself. Further, I am not convinced that it will be a 
necessary part of the solution.... it may be, but that needs to be 
demonstrated.
 
It may be that the "differences" are just a matter of semantics. I 
certainly do not suggest that ASN.1 be used to convey management 
data...but it isn't used now either. What is communicated over SNMP is the 
OID and the value. 
 
So I suggest that we start talking examples and scenarios to better define 
the scope and objectives. Then we can sort through them and see how to 
proceed.
 
Unfortunately, we are now in the middle of a snow storm and I must fight 
my way home, so my contribution will have to wait a while. But please, 
take advantage of the New England weather and beat me to the punch!
 
Bill Wagner
 
 
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Friday, February 07, 2003 2:41 PM
To: wbmm at pwg.org
Subject: WBMM> Differences


I'd like to try and resolve some of the (unfortunate) differences we are 
having regarding Charter, Scope, Requirements. 

>From what I can decipher, there is a well established interest in solving 
the problem "I've been getting at my (device)  management data remotely, 
within my enterprise just fine... but, now, how can I access it across the 
firewall" (maybe to provide services to multiple enterprises etc.). 

Others also want to solve... "... and what is the standard protocol and 
data model that lends itself to the web services environment that may be 
employed by proxy servers and/or directly in the embedded device". 

Of course, we will have legacy SNMP devices to manage for quite some time 
but I don't think the current existence of SNMP is the answer to the 2nd 
question. 
---------------------------------------------- 
Harry Lewis 
IBM Printing Systems 
---------------------------------------------- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20030207/59888952/attachment-0001.html


More information about the Wims mailing list