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

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?