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

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



Walter,

thanks for the message, this helps clarify things. I've just
re-read the NIM draft, and I think that we are crossing
wires because the requirements that you are referring to are
not in the draft (curiously enough, methods are ;-) )

Your position is summed up by your statement:

  > 2. For me, the primary value of the modeling
  >    activity is to define a consistent set of
  >    management interfaces to embedded systems.

This is the source of the problem - to me, an information
model is by definition independent not just of specific
repository and interface, but also of APIs and interfaces to
embedded systems.

So I would suggest that you revise the draft to include your
requirement for interfaces to embedded systems. However, I
still don't understand what these interfaces have to do with
the information model per se. Rather, these are a function
of the mapping from an information model to a data model.

The rest of the comments really depend on whether embedded
systems requirements should be a part of this effort, so
I'll defer commenting on them until that is cleared up.
However, your last two issues do need a comment:

With respect to my comment "Transactional semantics isn't in
the information model...", you write:

> This comment is contradictory with earlier statements
> you made. There are clearly elements that you want to
> model that are repository and protocol-specific.

No, it is not contradictory at all. The fact that there are
elements that are repository- and protocol-specific is why
they are in the mapping of an information model to a data
model and not in the information model.

> Events and User Access rights are both in the
> requirements doc. I believe you have endorsed
> including event notification in the information model.
> Yet, in your last comment you argue that transactional
> semantics are repository and protocol-specific and
> therefore should not be in the model.

What does event notification have to do with transactional
semantics? A notification is simply a message saying that an
entity has something interesting. It does NOT mean or imply
an operation that requires transactional semantics.

> Your previous statement also argues for a strategy that
> restricts the model to those features that are commonly
> available in a cross-section of protocols (something you
> argue against later in your last message).

Huh? I said, and I quote:

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

In other words, the information model should model the
information without regard to protocol or repository
limitations. The mapping can use the information model to
make up for the deficiencies of the repository or protocol.

> I also get the distinct impression that Andrea disagrees
> with you. One of Andrea's arguements for methods seems
> to be to encapsulate a behavior into a
> transaction (the reference to "go"):...

Well, we'll have to ask Andrea, but I don't get that
impression reading her quote. Please reread my above
explanation.

> If transactional semantics are not part of the model,
> the benefits of methods is greatly deminished. On the
> other hand, if they are part of the model, then my
> earlier example (and other examples I have not raised yet)
> raise some serious mapping issues that may undermine the
> overall benefits of the information model.

Please reread my above statement. I'm not arguing against
transactional semantics, and I don't know why you think I
am.

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


> John,
>
> Comments inline:
>
> > > >   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.
> >
> When I copied the quote, I noticed this as well :)
>
> > > 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 ;-) ).
> >
> I think we are crossing wires on two specific issues.
>
> 1. In many of your messages you refer to repositories. I
think repositories
> are interesting. However, for the IETF, the interfaces to
embedded systems
> are much more interesting than the interfaces to the
repository. I can use
> either a repository or a direct interface to the system to
manage the system
> as I described in my previous message on paradigms. But,
to manage a system,
> a repository may or may not be needed depending on the
paradigm. A
> repository is one potential mapping. But, as you say, a
repository and it's
> interface are but one application and LDAP is but one
mapping.
>
> 2. For me, the primary value of the modeling activity is
to define a
> consistent set of management interfaces to embedded
systems. This is what
> the COPS folks, the SNMPCONF folks and even the
traditional SNMP folks need
> right now. What I need to model are all things I wish to
expose. Now, there
> is this fussy line between the term behavior and interface
because when I
> change the configuration of a system, I am affecting the
behavior. However,
> if I wanted to model the system behavior, I might include
interfaces that
> are not pure management interfaces. For example, the
interface between
> routing and RSVP for detecting route flaps is an interface
but not a
> management interface. In a pure system model, I would
include this
> interface. In a management model, I would ignore it
becuase none of my
> management systems make use of it.
>
> > > 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.
> >
> See my comments above.
>
> > > 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.
> >
> What I said was that this bias tends to be the inclination
of the modelers.
> If you consider the DMTF networks and policy models, both
are very attribute
> centric. I would be hard pressed to name any methods in
either model (except
> the derived ones). By coincidence, the majority of
modelers in both
> activities had a decidedly repository-oriented set of
implementations in
> mind. In contrast, the DMTF systems and devices model has
many methods in
> them and coincidentally is strongly influenced by folks
who are defining
> programmatic interfaces to their systems. Now, this is not
necessarily
> intentional. It may well be an unconscious bias.
>
> This anicdotal experience suggests that the proper
modeling strategy has
> more to do with who is doing the modeling (as opposed to
the one true way).
> The debates over the best way to model a specific feature
and the diversity
> of opinions on how good a given model is reinforce this
perspective.
>
> Lastly, if you can't specify when to use methods, you not
only open yourself
> up to inconsistencies in the model but also
inconsistencies in the mappings.
> I happen to agree with Juergen that we must have mapping
guidelines. In
> addition, I don't think you can have mapping guidelines
without modeling
> guidelines.
>
> > 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).
>
> To me this is not a question of the value of methods or
the complexity of
> the mappings. In the past, I have relied on methods
frequently. The real
> question is the level of granularity with which an
interface is specified.
> If it is specified as a system with very granular
descriptions of what
> should happen, in what order, what all the potential
results are, etc., you
> are far closer to defining an implementation than an
interface. The question
> is: How black is the box (to what degree should an
interface model specify
> an implementation)? This has always been a problem with
standardizing
> management interfaces. There is an inherent tradeoff
between making the
> management system more explicit and forcing a specific
implementation
> (stifling diversity and innovation). I could safely argue
that the value of
> methods is in the explicit specification of an interface,
thereby resulting
> in a more precise implementation of the method
(irrespective of the mapping
> of the interface to a given protocol or API). With the
more explicit
> interface definition comes the inherent mapping issues. I
described one such
> mapping issue with my description of inconsistent
transactional semantics in
> different management paradigms.
> >
> > > 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.
>
> I provided the quote from the document to make this very
point. Here, you
> seem to be agreeing with its intent. We may be closer than
I thought.
> >
> > > >   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).
> >
> This comment is contradictory with earlier statements you
made. There are
> clearly elements that you want to model that are
repository and
> protocol-specific. Events and User Access rights are both
in the
> requirements doc. I believe you have endorsed including
event notification
> in the information model. Yet, in your last comment you
argue that
> transactional semantics are repository and
protocol-specific and therefore
> should not be in the model. Your previous statement also
argues for a
> strategy that restricts the model to those features that
are commonly
> available in a cross-section of protocols (something you
argue against later
> in your last message).
>
> I also get the distinct impression that Andrea disagrees
with you. One of
> Andrea's arguements for methods seems to be to encapsulate
a behavior into a
> transaction (the reference to "go"):
>
> "<Andrea> I do not understand the argument of having ONLY
attributes in a
> class definition and then hoping that some behavior
happens.  Is the goal to
> define an "object's" attributes and a "do something" bit?
IE, when I set
> the attributes and then hit "go", the right stuff happens?
This seems a
> formula for disaster and proprietary/unpredictable
behavior."
>
> If transactional semantics are not part of the model, the
benefits of
> methods is greatly deminished. On the other hand, if they
are part of the
> model, then my earlier example (and other examples I have
not raised yet)
> raise some serious mapping issues that may undermine the
overall benefits of
> the information model.
>
> ...
>
> > > 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.
> >
> I either completely disagree or completely misunderstand
what you are
> saying. There are many examples of portions of existing
models that are
> impossible to map. I have cited a number of them. The fact
is that different
> protocols have different capabilities. If they all had the
same capabilities
> we wouldn't have so many. Hence the features and
limitations of a protocol
> determine the subset of viable mappings in the model that
are available. If
> there is an event/notification mechanism in the model and
the model is
> mapped to LDAP, than that portion of the model is unusable
as long as LDAP
> does not support event notification. Again, you have two
choices:
> 1. limit the model to those mechansisms that are generally
available and
> easily (algorithmically) mapped and expand the model when
the protocols are
> extended.
> 2. construct a model that is unconcerned with specific
mappings recognizing
> that portions of the model will be unusable in certain
instances until the
> protocol or mapping has evolved.
>
> -Walter
>