Re: Methods in the NIM requirements

["John Strassner" <jstrassn@cisco.com>]

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
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>