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

["John Strassner" <jstrassn@cisco.com>]

Walter,

comments inline,

regards,
John

----- Original Message -----
From: "Weiss, Walter" <WWeiss@lucentctc.com>
To: "'John Strassner'" <jstrassn@cisco.com>;
<nim@ops.ietf.org>
Sent: Friday, May 05, 2000 12:43 PM
Subject: RE: NIM requirements/conventions (was Re: Methods
in the NIM requirements)


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

So my first point of disagreement is that this statement is
once
again focusing on attributes (e.g., "representing the
attribute's
relationships..."). An information model is much richer than
that,
and must focus on the modeling of objects. This is not
limited to
attributes, and in fact attributes may not be the primary
focus of
objects being modeled.

> The overall goal is to allow these attributes to be
equally applicable
> to protocols, programmatic interfaces, and repositories."

This I completely disagree with. This statement merges the
development
of an information model with a mapping to one or more data
models. These
are fundamentally different efforts, and combining them into
one is not
a good idea.

In other words, if the group is to focus on an information
model, then
it should focus on the information model independent of any
mapping
issues. Protocols and data structures are a function of
which data
store is chosen for the mapping, and APIs are a means to
store and
retrieve repository-specific information (e.g., the LDAP C
APIs don't
work very well against an RDBMS ;-) ).

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

Again, I completely disagree. The model should represent the
system, and
mappings should describe how to manipulate the objects
representing the
system and bind the model to application-specific uses.

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

We disagree here because the information model should use
whatever tools
it needs to properly describe a managed object and its
interaction with
the managed environment. This is why you can't make
statements about when
to use methods - it's really a function of what you are
modeling.

Saying that you aren't going to use methods because it makes
the model
map more easily to a protocol or data store will ultimately
ruin the
model, because it will ensure that the model is not
generally applicable.
It is the job of the mapping to map to limitations or extra
features of
a data store and its protocol(s).

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

And so far we have kept CIM implementation neutral. This is,
in fact, why
the LDAP Mapping WG was formed - to split off as a separate
process the
mapping of CIM information into a directory.

Bottom line is that the model should not be biased towards
any one
specific protocol or repository.

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

I don't understand this at all. Transactional semantics
isn't in the
information model because the ability to support
transactional and
referential integrity is repository and protocol-specific.
This is the
job of a mapping. If a repository, like a directory, can't
support
these features, then it is the job of the mapping to support
it in
some other way (e.g., by using middleware in conjunction
with the
directory to support the desired semantics).

The other reason that such semantics are not in the
information model
is because such semantics are application-specific. Not all
applications require these features.

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

We do neither.

The first approach is not doable because one can't
instantiate an
information model. The information model represents objects
and their
inter-relationships, not protocols and paradigms.

The second approach is just as bad because:
  1) protocols, repositories and APIs deine mappings, not
info models
  2) by having a mapping drive an information model, the
type of data
     and the relationships between different objects will be
dictated
     not by the system that you are modeling, but by the
protocol or
     repository that you are using. (I see no relationship
between
     APIs and the info model).

What we should do is agree on what it is that we want to
model, and model.
We can then investigate a set of mappings to specific data
models. But
the mappings come after the info model is done, not before.

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