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

["Weiss, Walter" <WWeiss@lucentctc.com>]

John,

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

I am trying to figure out where we are miscommunicating. In the requirements
spec, the text says:

"This document only describes the requirements for the definition of 
common attributes, mechanisms and conventions for their organization 
into reusable data structures, and mechanisms for representing the 
attribute's relationships to other attributes and structures. The 
overall goal is to allow these attributes to be equally applicable 
to protocols, programmatic interfaces, and repositories."

My view here is that the model is not describing the system per se. Rather,
it is describing the interfaces for interacting with (determining the status
and changing the the operational characteristics of) the system. Now, there
are a number of ways to interact with a system. You are correct in asserting
that the process of converting an information model to a programmatic
interface (API) is a mapping. The fact is that methods map very nicely to
programmatic interfaces. The issue is not with the mapping. Rather the issue
is with the range of paradigms that we would like to support with this
model. If we bias the model strongly towards deployment through APIs, we
would be inclined to use methods pervasively because programmatic interfaces
are defined in terms of function calls. If we were to bias the model
strongly towards repository oriented applications, we would strongly favor
an attribute model. If we considered the management interfaces provided
through protocols such as SNMP, we would again be inclined to lean towards
an attribute centric model.

Historically, we have tried to be implementation neutral in CIM. However,
time after time specific tradeoffs have been made in the model to avoid
problems with specific mappings. I can't count the number of times that
someone wanted to make a change to CIM because it was problematic for LDAP.
Don't get me wrong. I aggree that we should be sensative to mapping issues.
In fact, what the requirements doc is saying is that in NIM we should be
sensative multiple mappings.
 
>   2) I do understand push and pull. I
>      don't understand what they have
>      to do with the info model.

LDAP, COPS, and SNMP all have various strengths and weaknesses. Some
weaknesses are a result of the protocol and can be addressed with protocol
enhancements. Other weaknesses are a result of the paradigm under which the
protocols operate. My earlier reference to transactional semantics is a
specific example of weaknesses that at least in part are a result of the
paradigm. In some cases contradictions between the info model and the
weakness of the paradigm prevent a viable mapping.

So we have to ask ourselves a question. Do we assume that the protocols (and
paradigms) will be altered to fit the ideal info model or do we adjust the
info model to optimize the mappings to the broadest cross-section of
paradigms and protocols/repositories/programmatic interfaces. If we claim
the former, then the additional requirement I am suggesting is uninteresting
because we will assume a specific paradigm for the model and change the
protocols or restrict the set of protocols to those that can conform to the
paradigm defined in the model. If we agree on the latter, then we need some
guidelines for modeling that take the issues associated with the various
paradigms into consideration.

regards,

-Walter

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