[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Methods in the NIM requirements



Andrea,

My words may have been ill-chosen. It may have been more appropriate to say
repository. I believe I addressed the remainder of your comment with my last
note to John.

-Walter

> -----Original Message-----
> From: Andrea Westerinen [mailto:andreawest@mindspring.com]
> Sent: Saturday, April 29, 2000 9:05 PM
> To: Weiss, Walter; 'John Strassner'; nim@ops.ietf.org
> Subject: RE: Methods in the NIM requirements
> 
> 
> Walter, You are confusing the info model with specific 
> implementations.  You
> certainly can map both data and methods into repositories and 
> protocols.
> 
> But, if you really want to restrict the model to "how is the model
> applicable to the directory" (your words), then you don't need an info
> model, nor any real-time/dynamic DATA (since again using your words,
> "directories are not well suited for real-time status 
> representations").
> You just need a data model for a directory.  However, I 
> believe that this
> defeats your own goals for NIM.
> 
> Andrea
> 
> > -----Original Message-----
> > From: owner-nim@ops.ietf.org 
> [mailto:owner-nim@ops.ietf.org]On Behalf Of
> > Weiss, Walter
> > Sent: Friday, April 28, 2000 10:44 AM
> > To: 'John Strassner'; nim@ops.ietf.org
> > Subject: RE: Methods in the NIM requirements
> >
> >
> > John,
> >
> > Sorry for the dalay. The point is that the requirements document
> > specifically seeks an information model which is equally 
> applicable to a
> > protocol, repository, and API. Therefore, I may want to use 
> a NIM defined
> > data structure to represent an interface via SNMP or I may 
> want to use the
> > same data structure to represent the state of a device in a
> > repository, or I
> > may want to use the repository distribute data structure to 
> devices as
> > configuration. In the last case, the paradigm suggests a 
> write to the
> > directory from a management entity and a read from the 
> device to retrieve
> > the configuration. As neither of the operations in this 
> paradigm could be
> > considered as real-time, the "go" semantic is at best ambiguous.
> >
> > regards,
> >
> > -Walter
> >
> > > ??? An information model is independent of any specific type
> > > of repository. What does the directory have to do with
> > > anything?
> > >
> > > regards,
> > > John
> >
> > > > I think Keith's point is accurate (and I phrased my point
> > > poorly), SNMP
> > > > assumes a memory map model. Therefore, the protocol *and*
> > > the data
> > > > structures assume an interactive relationship with the
> > > device (a "go" in
> > > > Andrea's terms). But I think we are refining the
> > > parameters of the question
> > > > without discussing the question directly. If the NIM model
> > > implies a "go"
> > > > semantic, how is the model applicable to the directory. If
> > > I have a method
> > > > for reboot that means do it now, how do I represent the
> > > current state
> > > > (rebooting/(re)initializing/unavailable) of the machine
> > > in a directory.
> > > > "Go" implies real-time semantics, yet we all know that
> > > directories are not
> > > > well suited for real-time status representations.
> > > >
> > > > regards,
> > > >
> > > > -Walter
> > > >
> > > > > -----Original Message-----
> > > > > From: remoore@us.ibm.com [mailto:remoore@us.ibm.com]
> > > > > Sent: Wednesday, April 19, 2000 7:40 AM
> > > > > To: Weiss, Walter
> > > > > Cc: nim@ops.ietf.org
> > > > > Subject: RE: Methods in the NIM requirements
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Walter,
> > > > >
> > > > > You've said this twice now:
> > > > >
> > > > > >Should the semantics of "go" be in the model? If we
> > > look at many
> > > > > >of the models out there today, all have "go" semantics.
> > > However,
> > > > > >most are in the protocol itself. The SET command is
> > > part of SNMP,
> > > > > >not the MIB.
> > > > >
> > > > > >In contrast, when the model is applied to a management
> > > protocol
> > > > > >(SNMP), actions are implied by the protocol (GETs and
> > > SETs).
> > > > >
> > > > > But it isn't true.  The semantics of SNMP's SET command
> > > itself
> > > > > are simply changing the value of a MIB object
> > > (attribute).  If an
> > > > > SNMP SET is going to have side effects, these *must* be
> > > specified
> > > > > in the MIB definition of the object being SET.
> > > > >
> > > > > The *protocol* operation that embodies the concept of an
> > > action is
> > > > > (not surprisingly) CMIS/CMIP's M-ACTION operation.
> > > > >
> > > > >
> > > > > Regards,
> > > > > Bob
> > > > >
> > > > > Bob Moore
> > > > > IBM Networking Software
> > > > > +1-919-254-4436
> > > > > remoore@us.ibm.com
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
>