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

Re: Methods in the NIM requirements



comments inline
----- Original Message -----
From: "David Harrington" <dbh@cabletron.com>
To: "John Strassner" <jstrassn@cisco.com>
Cc: "Weiss, Walter" <WWeiss@lucentctc.com>;
<nim@ops.ietf.org>
Sent: Monday, May 01, 2000 10:33 AM
Subject: Re: Methods in the NIM requirements


> Hi,
>
> I believe what Walter has been trying to address is
backwards
> compatibility with existing practices. We have ten years
worth of MIBs
> to consider, plus additional data models for other
protocols.

No one is ignoring the MIBs and other protocols. If you
would actually look at one of the models, you would realize
that it already maps some MIB information. This was true of
CIM and DEN 2 years ago, and is true of the Policy models
that have been recently published as IETF drafts.

> I would consider it inappropriate to start from scratch
with an
> information model and not consider all the IETF standards
work that
> needs to be able to map to that information model.

So would I, but luckily we're not. ;-)

> Part of the information model will be the attributes
contained within
> the objects, part will be methods. In an ideal
object-oriented world,
> those methods would provide the interface to the
attributes, even if
> they were just get()/set() methods.

Umm, no. You can call me a theorist if you want, but any OO
system uses a much richer mechanism that just get and set
methods. Please feel free to check the book references that
I gave earlier if you don't believe me. The point is that
methods implement behavior, and get and set methods are not
behavior.

> IETF standards have generally NOT been object-oriented.
They define sets
> of attributes, and then have a separate set of commands to
manipulate
> those sets of attributes directly.

So therefore we should never use OO techniques? We should
always just have sets of attributes through the next
century? I'm sorry, but I don't get your point.

> I have not seen a convincing explanation of how NIM will
model the
> existing sets of attributes and protocol commands. I think
that is what
> Walter is trying to get from you and Andrea and others,
who seem to be
> ignoring the existing bottom-up body of work. The
abstractions used in
> the NIM should be representative of the existing data
models, such as
> SNMP and LDAP, not just soemthing pulled from blue sky
theories.

Geez, if you please LOOK at some of the work that is done
before condemning modelers as theoreticians who can't spell
a MMixqB ;-)

The Policy Framework working group has developed:
  a generic info model AND a mapping to an LDAP schema
  a policy QoS info model AND a mapping to an LDAP schema
  a device QoS info model (schema work starting to be done)

The QoS info model is closely aligned with not only the
DiffServ conceptual model, but also the DiffServ MIB (yes, I
said MIB, and didn't even mis-spell it).

The Network Model of DEN models MIB variables in a score of
RFCs.

So please, before you condemn, listen to both sides first.

> Walter seems to be asking how the theoretical information
models and
> existing data models will be mapped, and he is getting
flak for asking
> the questions.

I just gave you several examples.

> dbh
>
> John Strassner wrote:
> >
> > Walter,
> >
> > sorry, but it is you that are missing the point. Please
> > reread my message, which was in response to this excerpt
> > from yours:
> >
> > >>The point is that the requirements document
> > >>specifically seeks an information model which
> > >>is equally applicable to a protocol,
> > >>repository, and API.
> >
> > So it is indeed you that is talking about protocols and
> > APIs, which are NOT part of an information model, but
ARE
> > part of mapping that information model.
> >
> > Furthermore, you continue to ignore basic issues, like
what
> > an information model is defined as. You continually try
to
> > separate attributes from methods, which goes against the
> > majority's thinking. You continually try to press
examples
> > such as your "go semantics" on a model when "go
semantics"
> > will be implemented differently by different mappings of
the
> > information model.
> >
> > I could go on, but Andrea and Lakshmi already hit a
number
> > of other applicable points.
> >
> > In summary, you are the only person that is continuing
this
> > trying conversation about methods in NIM. You have
> > absolutely no support from anyone else in the group.
Please
> > end this now.
> >
> > John
> > ----- Original Message -----
> > From: "Weiss, Walter" <WWeiss@lucentctc.com>
> > To: "'John Strassner'" <jstrassn@cisco.com>;
> > <nim@ops.ietf.org>
> > Sent: Monday, May 01, 2000 8:49 AM
> > Subject: RE: Methods in the NIM requirements
> >
> > > John,
> > >
> > > Your personalized comments aside, you seem to
consistently
> > be missing the
> > > point. The point is not about protocols but about
> > paradigms (push vs. pull,
> > > real-time vs. non-real-time, etc.) The examples I
provided
> > were taken from
> > > LDAP because it happened to demonstrate a specifically
> > different paradigm.
> > > SQL also operates on the same paradigm. Please go back
and
> > reread my
> > > question in this light.
> > >
> > > regards,
> > >
> > > -Walter
> > >
> > > > -----Original Message-----
> > > > From: John Strassner [mailto:jstrassn@cisco.com]
> > > > Sent: Friday, April 28, 2000 5:16 PM
> > > > To: Weiss, Walter; nim@ops.ietf.org
> > > > Subject: Re: Methods in the NIM requirements
> > > >
> > > >
> > > > Huh?
> > > >
> > > > The point is that an information model, by
definition
> > that
> > > > we have already agreed to in previous IETF
discussions,
> > is
> > > > INDEPENDENT of any specific repository and protocol.
> > > > Otherwise, you could never get two different
mappings to
> > two
> > > > different repositories and/or protocols to
interoperate.
> > > >
> > > > I have no idea where APIs entered the picture. APIs
are
> > > > implementation-specific. You can not implement an
> > > > information model directly, you must first map the
data
> > in
> > > > an information model to a form appropriate for a
> > specific
> > > > repository, taking into account the way its access
> > > > protocol(s) operate.
> > > >
> > > > You seem obsessed with implementation issues, but
these
> > are
> > > > NOT appropriate for an information model discussion.
> > These
> > > > are appropriate for the data models that are derived
> > from an
> > > > information model. Please stop trying to combine
them.
> > > >
> > > > John
> > > > ----- Original Message -----
> > > > From: "Weiss, Walter" <WWeiss@lucentctc.com>
> > > > To: "'John Strassner'" <jstrassn@cisco.com>;
> > > > <nim@ops.ietf.org>
> > > > Sent: Friday, April 28, 2000 10:43 AM
> > > > Subject: RE: Methods in the NIM requirements
> > > >
> > > >
> > > > > John,
> > > > >
> > > > > Sorry for the dalay. The point is that the
> > requirements
> > > > document
> > > > > specifically seeks an information model which is
> > equally
> > > > applicable to a
> > > > > protocol, repository, and API. Therefore, I may
want
> > to
> > > > use a NIM defined
> > > > > data structure to represent an interface via SNMP
or I
> > may
> > > > want to use the
> > > > > same data structure to represent the state of a
device
> > in
> > > > a repository, or I
> > > > > may want to use the repository distribute data
> > structure
> > > > to devices as
> > > > > configuration. In the last case, the paradigm
suggests
> > a
> > > > write to the
> > > > > directory from a management entity and a read from
the
> > > > device to retrieve
> > > > > the configuration. As neither of the operations in
> > this
> > > > paradigm could be
> > > > > considered as real-time, the "go" semantic is at
best
> > > > ambiguous.
> > > > >
> > > > > regards,
> > > > >
> > > > > -Walter
> > > > >
> > > > > > ??? An information model is independent of any
> > specific
> > > > type
> > > > > > of repository. What does the directory have to
do
> > with
> > > > > > anything?
> > > > > >
> > > > > > regards,
> > > > > > John
> > > > >
> > > > > > > I think Keith's point is accurate (and I
phrased
> > my
> > > > point
> > > > > > poorly), SNMP
> > > > > > > assumes a memory map model. Therefore, the
> > protocol
> > > > *and*
> > > > > > the data
> > > > > > > structures assume an interactive relationship
with
> > the
> > > > > > device (a "go" in
> > > > > > > Andrea's terms). But I think we are refining
the
> > > > > > parameters of the question
> > > > > > > without discussing the question directly. If
the
> > NIM
> > > > model
> > > > > > implies a "go"
> > > > > > > semantic, how is the model applicable to the
> > > > directory. If
> > > > > > I have a method
> > > > > > > for reboot that means do it now, how do I
> > represent
> > > > the
> > > > > > current state
> > > > > > > (rebooting/(re)initializing/unavailable) of
the
> > > > machine
> > > > > > in a directory.
> > > > > > > "Go" implies real-time semantics, yet we all
know
> > that
> > > > > > directories are not
> > > > > > > well suited for real-time status
representations.
> > > > > > >
> > > > > > > regards,
> > > > > > >
> > > > > > > -Walter
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: remoore@us.ibm.com
> > [mailto:remoore@us.ibm.com]
> > > > > > > > Sent: Wednesday, April 19, 2000 7:40 AM
> > > > > > > > To: Weiss, Walter
> > > > > > > > Cc: nim@ops.ietf.org
> > > > > > > > Subject: RE: Methods in the NIM requirements
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Walter,
> > > > > > > >
> > > > > > > > You've said this twice now:
> > > > > > > >
> > > > > > > > >Should the semantics of "go" be in the
model?
> > If we
> > > > > > look at many
> > > > > > > > >of the models out there today, all have
"go"
> > > > semantics.
> > > > > > However,
> > > > > > > > >most are in the protocol itself. The SET
> > command is
> > > > > > part of SNMP,
> > > > > > > > >not the MIB.
> > > > > > > >
> > > > > > > > >In contrast, when the model is applied to a
> > > > management
> > > > > > protocol
> > > > > > > > >(SNMP), actions are implied by the protocol
> > (GETs
> > > > and
> > > > > > SETs).
> > > > > > > >
> > > > > > > > But it isn't true.  The semantics of SNMP's
SET
> > > > command
> > > > > > itself
> > > > > > > > are simply changing the value of a MIB
object
> > > > > > (attribute).  If an
> > > > > > > > SNMP SET is going to have side effects,
these
> > *must*
> > > > be
> > > > > > specified
> > > > > > > > in the MIB definition of the object being
SET.
> > > > > > > >
> > > > > > > > The *protocol* operation that embodies the
> > concept
> > > > of an
> > > > > > action is
> > > > > > > > (not surprisingly) CMIS/CMIP's M-ACTION
> > operation.
> > > > > > > >
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Bob
> > > > > > > >
> > > > > > > > Bob Moore
> > > > > > > > IBM Networking Software
> > > > > > > > +1-919-254-4436
> > > > > > > > remoore@us.ibm.com
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
>