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

Re: Methods in the NIM requirements



Walter,

sorry, but it is you that are missing the point. Please
reread my message, which was in response to this excerpt
from yours:

>>The point is that the requirements document
>>specifically seeks an information model which
>>is equally applicable to a protocol,
>>repository, and API.

So it is indeed you that is talking about protocols and
APIs, which are NOT part of an information model, but ARE
part of mapping that information model.

Furthermore, you continue to ignore basic issues, like what
an information model is defined as. You continually try to
separate attributes from methods, which goes against the
majority's thinking. You continually try to press examples
such as your "go semantics" on a model when "go semantics"
will be implemented differently by different mappings of the
information model.

I could go on, but Andrea and Lakshmi already hit a number
of other applicable points.

In summary, you are the only person that is continuing this
trying conversation about methods in NIM. You have
absolutely no support from anyone else in the group. Please
end this now.

John
----- Original Message -----
From: "Weiss, Walter" <WWeiss@lucentctc.com>
To: "'John Strassner'" <jstrassn@cisco.com>;
<nim@ops.ietf.org>
Sent: Monday, May 01, 2000 8:49 AM
Subject: 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
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>