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

Re: NIM requirements/conventions (was Re: Methods in the NIM requirements)



Walter,

I'm still confused:

  1) you still didn't tell me why an
     information model needs to be
     concerned with APIs. Isn't that
     a problem in building the
     data model mapping?

  2) I do understand push and pull. I
     don't understand what they have
     to do with the info model.

Thanks for your patience.

John
----- Original Message -----
From: "Weiss, Walter" <WWeiss@lucentctc.com>
To: "'John Strassner'" <jstrassn@cisco.com>; "'Mark A.
Carlson'" <mark.carlson@sun.com>; <nim@ops.ietf.org>
Sent: Wednesday, May 03, 2000 3:11 PM
Subject: RE: NIM requirements/conventions (was Re: Methods
in the NIM requirements)


> Hi John,
>
> Comments follow where you requested:
>
> > A couple of quick points (up here rather than inline due
to
> > the nesting).
> >
> > > > An information model needs to be able to be
> > > > mapped to any number of data models such as:
> > > >
> > > > Repositories - Directories, databases, etc.
> > > > Protocols - SNMP
> > > > APIs - C++, Java, etc.
> >
> > Not to be anal-retentive, but I think you really need to
> > conside the repository in conjunction with the protocol
when
> > you do a mapping. For example, in doing an LDAP mapping,
the
> > protocol places a number of constraints on what can be
> > stored in and retrieved from the data store.
> >
> > I'm not convinced that APIs affect the structure of data
in
> > the information model; they certainly must be considered
> > when mapping to a specific repository.
> >
> > > ... me to believe that we should also expand this
> > > to describe supported paradigms, since protocols
> > > are an embodyment of a paradigm.
> >
> > Perhaps, though I'm having some trouble getting my head
> > around modeling push vs. pull semantics. This could
easily
> > be done in a data flow model, but we're talking about an
> > information model. Walter, if you could elaborate a bit,
> > that would certainly help.
>
> SNMP and COPS PR are both push models. A configuration
change is pushed into
> the device via the protocol. The fact that these protocols
acknowledge the
> change request in effect makes the protocol transactional
or synchronous.
> There are exceptions within this paradigm/protocol that
make the
> acknowledgement, and therefore the transactional semantics
ambiguous.
> However, let's ignore that for the moment.
>
> With LDAP and COPS the model is a pull. The device makes a
request to a
> shared resource such as a policy server or a directory. It
is quite
> conceivable that the instance being requested through the
request is shared
> by multiple devices. For example a user identity to
address mapping exists
> as one instance in the repository or server. Yet this
instance can be shared
> by any number of devices. Therefore, a change to the
identity/address
> mapping in the policy server/directory does not result in
a
> synchronous/transactional change in the device. In the
case of LDAP, this is
> because of notification limitations in the protocol. In
the case of COPS, it
> is because a single change can result in many device
changes resulting in
> ambiguous transactional semantics. In some devices the
change succeeded, in
> others if failed, other devices were unreachable or
offline, etc.
>
> > > > Object properties that only have the semantics
> > > > of READ/WRITE or READ-only are (by convention?)
> > > > called ATTRIBUTES. (Is this correct?)...
> > > >
> > > Yes.
> >
> > Sorry, I disagree. Attributes and properties are
synonyms. A
> > property represents something that is used to describe
some
> > aspect of a class. One can in the model define more
> > elaborate semantics (e.g., a transitory attribute whose
> > lifetime is some subset of the object's lifetime) if it
> > makes sense. Of course, this may present some mapping
> > difficulties...
>
> Mark, are you really trying to come up with a term or are
you suggesting
> that most properties in a model will have READ/WRITE
semantics?
>
> -Walter
>
>