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

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



I find it amusing that:

  1) methods were defined as requirements in the
     document, yet you tried to remove them in
     the discussions in this list
  2) nowhere in the requirements document is
     there any mention of APIs and interfaces
     to embedded systems, yet this is your
     primary focus
  3) you continue to confuse the definition of an
     information model with the mapping of its
     data to a data model (in fact, here is a
     quote from the NIM draft:

     "From this idealized information model,
     implementation-specific data models (which
     are bound to specific types of repositories
     and data storage and retrieval mechanisms,
     protocols, APIs, etc.) can be derived...")

     which clearly means, develop the information
     model first, and THEN develop the data model.
     But you characterize such work as "too
     abstract" or not being of value because it
     was written in a book.

But what really depresses me is your continued attempts to
pigeon-hole Andrea and me as "modelers" with the implication
that we're not engineers. And with respect to your "I'm not
going to slam the modelers...but I will anyway" diatribe,
that was just too insulting to merit a response.

So go ahead and design your data models without methods (you
say that you argue both sides, but in fact you haven't) and
without all of the theoretical mumbo-jumbo that you
associate me (and Andrea) with, since clearly all I am to
you is a book librarian. I'll just work on shipping
real products.

John
----- Original Message -----
From: "Weiss, Walter" <WWeiss@lucentctc.com>
To: "'John Strassner'" <jstrassn@cisco.com>;
<nim@ops.ietf.org>
Sent: Tuesday, May 16, 2000 8:53 AM
Subject: 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.
>
> <snip>
>
> > 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.
>
> regards,
>
> -Walter
>
>