WBMM> Differences

WBMM> Differences

WBMM> Differences

TAYLOR,BOB (HP-Vancouver,ex1) bobt at hp.com
Mon Feb 10 14:18:32 EST 2003


As for HTTP/XML/SOAP (& WSDL, XSD, etc.), I suspect there is some notion of
a requirement there that we need to be more explicit about.  I think part of
the justification for this effort (at least from HP) is alignment with the
new round of IT & management technologies, for a variety of reasons - align
management with other web services oriented work (e.g., PSI), better align
with broader IT management technology directions, etc..  My point is that I
don't think we're actually neutral on this.  We may want to consider other
alternatives, but part of our requirements will likely include an explicit
bias toward a set of technology "answers" that we need to align with.
 
bt

-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Saturday, February 08, 2003 9:38 PM
To: Wagner,William
Cc: wbmm at pwg.org
Subject: RE: WBMM> Differences



Sounds to me like we are nearly in violent agreement. I thought it was you
who coined the phrase "MIB replacement" in the thread.. so I was just trying
to speak your language. I agree we should probably articulate the charter
such that reasonable alternatives may be considered or discovered... but I
think we should also acknowledge all 3 or 4 most vocal and interested
parties (so far) seem to "anticipate" the application of HTTP and XML to get
the job done. When we built the (very successful) Printer MIB standard... we
did not embark in a vague or general direction... I feel being as specific
as we can about our goal will help us achieve better results sooner.   
---------------------------------------------- 
Harry Lewis 
IBM Printing Systems 
---------------------------------------------- 



	"Wagner,William" <WWagner at NetSilicon.com> 
Sent by: owner-wbmm at pwg.org 


02/08/2003 06:49 PM 

        
        To:        Harry Lewis/Boulder/IBM at IBMUS 
        cc:        <wbmm at pwg.org> 
        Subject:        RE: WBMM> Differences



Harry,

At least  we both agree with Cathy.

To answer your questions:

a. Replacing MIBs as an object itself would inherently self justify the
effort.  However, as a part of a solution, the need for such an effort must
be justified. 

b. You can define a PWG activity which, for the various  reasons you have
cited, determines that developing a replacement for MIBs is a justifiable
object in  itself. Quite frankly, I am not sure that I even understand what
you mean  by a replacement for MIBs, and I suggest that some examples may
help.   

Regardless, at this point, your own position is that we have not adequately
scoped out the WBMM. Therefore, to preserve some order, I suggest that we
should not be considering solutions to a problem we have not defined, but
continue in an orderly way to scope out the objective.

Indeed, even though I would agree that I see little alternative to  HTTP,
probably XML, and quite possible SOAP as being components of the solution, I
would not define these in the objectives or even the requirements. Nor would
I refuse to entertain alternate ideas if reasonable ones were offered.
Again, I think that short-circuits the development process.

Bill Wagner




                -----Original Message----- 
                From: Harry Lewis [mailto:harryl at us.ibm.com] 
                Sent: Fri 2/7/2003 3:28 PM 
                To: Wagner,William 
                Cc: wbmm at pwg.org 
                Subject: RE: WBMM> Differences
                
                

                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/20030210/67ab5585/attachment-0001.html


More information about the Wims mailing list