[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Methods in the NIM requirements

To: John Strassner <jstrassn@cisco.com>
Subject: Re: Methods in the NIM requirements
From: David Harrington <dbh@cabletron.com>
Date: Mon, 01 May 2000 13:33:11 -0400
CC: "Weiss, Walter" <WWeiss@lucentctc.com>, nim@ops.ietf.org
Delivery-date: Mon, 01 May 2000 10:40:08 -0700
Envelope-to: nim-data@psg.com
Organization: Enterasys
Hi,

I believe what Walter has been trying to address is backwards
compatibility with existing practices. We have ten years worth of MIBs
to consider, plus additional data models for other protocols. 

I would consider it inappropriate to start from scratch with an
information model and not consider all the IETF standards work that
needs to be able to map to that information model.

Part of the information model will be the attributes contained within
the objects, part will be methods. In an ideal object-oriented world,
those methods would provide the interface to the attributes, even if
they were just get()/set() methods.

IETF standards have generally NOT been object-oriented. They define sets
of attributes, and then have a separate set of commands to manipulate
those sets of attributes directly.

I have not seen a convincing explanation of how NIM will model the
existing sets of attributes and protocol commands. I think that is what
Walter is trying to get from you and Andrea and others, who seem to be
ignoring the existing bottom-up body of work. The abstractions used in
the NIM should be representative of the existing data models, such as
SNMP and LDAP, not just soemthing pulled from blue sky theories.

Walter seems to be asking how the theoretical information models and
existing data models will be mapped, and he is getting flak for asking
the questions.

dbh

John Strassner wrote:
> 
> 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
Prev by Date: RE: Methods in the NIM requirements
Next by Date: Re: Methods in the NIM requirements
Prev by thread: RE: Methods in the NIM requirements
Next by thread: Re: Methods in the NIM requirements
Index(es):
- Date
- Thread