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

> 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.
Perhaps I should use a new term instead of "management interfaces". Whenever
I use this term, you and Andrea both assume I am talking about an
implementation. However, what I mean is, a set of data structures (and
possibly methods) that can be mapped to a predetermined set of protocols,
APIs, and repositories. This is not the main point though. NIM was intended
to address a specific set of concrete problems with concrete solutions. Let
me try to clarify what I mean here.

First, let's consider the problem domain. In the requirements doc, we tried
to describe some of the issues facing network management systems. As I see
it, there are two really big problems. First, with the advent of new
(standardized) technologies (DiffServ, MPLS, ...), we are increasing the
number of "knobs" available to a management system at an alarming rate.

Second, there is an increasing variety of alternative network management
solutions (paradigms) available. I have posted many messages listing all the
alternatives vendors and customers are currently considering. From a
practical standpoint, vendors have to support most of these alternative
approaches to stay competitive and meet specific customer/market
requirements. The result is a multiplicative effect on the number of "knobs"
that a given product needs to support. Because each protocol/paradigm
defines many of these "knobs" differently, inconsistencies have to be
resolved in the box (adding complexity and making each protocol-specific
interface more ambiguous).

Clearly having a consistent definition of the data structures across various
protocols would significantly simplify both the implementation of these data
structures in devices and the interpretation of the structures by management
systems. This clearly implies an information model that is implementation
independent. By starting with on "generic" set of data structures, it
greatly reduces the burden of the subject matter experts from having to
determine a reasonable set of data structures for each protocol and then
trying to make them consistent with each other to defining a single set of
data structures that can be mapped to each protocol. Since programmatic
management interfaces are also defined for many technologies, a mapping of
the "generic" data structures is applicable as well.

As I see it, there are two extremes that we have been discussing. One
extreme is to continue the way we have been going with many protocols and
many different representations of similar protocol-specific interfaces.
IMHO, this approach does not scale. Eventually, customers are likely to
reject all the new technologies as adding too much complexity (and
management overhead) to their networks. In many problem domains, they are
doing this already. At the other extreme, we have an inherently complex
model. The complexity is a result of too much flexibility in the model (the
"art" element), too great a dependence on modeling experts (as opposed to
the rank and file engineer), and a lack of consideration for mapping issues
until after the model is complete (significant delays in deployment).

Let me be clear. This is not a slam at modelers or the research done to date
on proper modeling techniques. Rather, it is a slam at, what I consider,
arguments of the abstract rather than concrete. When I see folks saying that
things have to be done a particular way because a book says so or that
modeling is an art form, I get very nervous at a practical "can we make this
work" level. That does not mean it can't work. It only means that as an
engineer, I get nervous about the practical viability of the activity in the
context of a very practical and technical environment like the IETF.

What I would prefer is a middle ground. I would like to model data
structures specifically for the purpose of managing various networking
related technologies. I would like to develop these structures with specific
mappings in mind, recognizing that this limits the model, but also
recognizing that this will speed up the mapping and deployment process (a
crucial element for any successful IETF activity). I favor modeling
guidelines to make it easier for engineers to develop consistent models. I
also favor algorithmic mappings of the model to specific protocols wherever
possible. Past experience with LDAP mappings of CIM make me question whether
this is viable in all cases. However, algorithmic mappings are another
component that will speed up the mapping and deployment process.

Now maybe what I am looking for is too concrete to be called a model. Maybe
it should be called something like a functional interface definition. If
that is the case, so be it.


> 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.
I didn't think the model was for defining the message but rather the process
of registering for an event. This may or may not send a message depending on
the paradigm. However, the point I was trying to make is that events are
very protocol and interface specific. Some protocols and interfaces are
capable of supporting it while others are not. Similarly, Access Rights are
supported in some protocols and not in others. By your earlier definition,
this makes both protocol specific.

> > 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.
While I agree that the model should be protocol and repository independent,
this text is a little too strong for me (as you probably gathered from my
comments above :) However the text you wrote that I was refering to in my
comment was:

"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 text suggests that the criteria for modeling something is that it can't
be repository and protocol-specific. Hence, my confusion relative to the
Event Registration and User Access Rights, which clearly meet your criteria
for not being included in the model.

> > 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.
When I get to Andrea's reply, I will no doubt find some other criteria that
does justify the use of methods ;)

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

Thanks. In reality, I am not arguing against methods myself. I am only
concerned about the mappings of methods and identifying some concrete
benefits that I can translate into helpful guidelines.