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

RE: Methods in the NIM requirements



John,

Your personalized comments aside, you seem to consistently be missing the
point. The point is not about protocols but about paradigms (push vs. pull,
real-time vs. non-real-time, etc.) The examples I provided were taken from
LDAP because it happened to demonstrate a specifically different paradigm.
SQL also operates on the same paradigm. Please go back and reread my
question in this light.

regards,

-Walter 

> -----Original Message-----
> From: John Strassner [mailto:jstrassn@cisco.com]
> Sent: Friday, April 28, 2000 5:16 PM
> To: Weiss, Walter; nim@ops.ietf.org
> Subject: Re: Methods in the NIM requirements
> 
> 
> Huh?
> 
> The point is that an information model, by definition that
> we have already agreed to in previous IETF discussions, is
> INDEPENDENT of any specific repository and protocol.
> Otherwise, you could never get two different mappings to two
> different repositories and/or protocols to interoperate.
> 
> I have no idea where APIs entered the picture. APIs are
> implementation-specific. You can not implement an
> information model directly, you must first map the data in
> an information model to a form appropriate for a specific
> repository, taking into account the way its access
> protocol(s) operate.
> 
> You seem obsessed with implementation issues, but these are
> NOT appropriate for an information model discussion. These
> are appropriate for the data models that are derived from an
> information model. Please stop trying to combine them.
> 
> John
> ----- Original Message -----
> From: "Weiss, Walter" <WWeiss@lucentctc.com>
> To: "'John Strassner'" <jstrassn@cisco.com>;
> <nim@ops.ietf.org>
> Sent: Friday, April 28, 2000 10:43 AM
> 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
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
>