Here are the NIM BOF meeting minutes. I would like to thank the note takers (Steve Moulton, Glen Waters, and Bob Moore) and Jeff for pulling it all together and providing a summary for the faint of heart.
Regards,
-Walter
=========================================================================
NIM BOF Summary
48th IETF
Pittsburgh, PA, USA
August 2,
2000
Summary:
The Network Information Model (NIM) Birds of a Feather Session
(BOF)
met on Tuesday, August 2, 2000. The purpose
of the BOF was to prepare
and advance a recommendation
on whether a new Working Group should be
chartered to
address the duplication of effort resulting from disparate
data structures being defined that cross the various management
protocols
and methodologies.
The problem was introduced. The proposed approach is to
use or specify a
language that describes the attribute
and method relationships with enough
detail that a
mechanical means for mapping those structures to specific
protocols can be supported. This should include determining the
process for
defining and aligning various
technology-specific models to maximize reuse
and
consistency and to insure there are mechanical/algorithmic means for
going to and from the model and the various technology-specific
data
structures (MOFs, PIBs, MIBs, etc).
There appears to be a wealth of related technology, tools, and
techniques that
can be leveraged and adapted to the
problem. These are available at both
levels, i.e.,
the level of the information model and for various data models,
e.g., SMI/MIB, SPPI/PIB, SMIng.
The current draft of the strawman requirements document was
presented. It
provides a good start, but is not
yet complete nor universally accepted.
The general consensus appears to be that it is:
a) desirable to have
convergence of the various information models
in use
within the IETF,
b) highly desirable to have
convergence of the various data models,
data
structures, and data definition languages in use within the
IETF and
under study by the IRTF, i.e., SMI/MIB, SPPI/PIB, and
SMIng,
c) a
requirement for automated algorithmic mappings between the
resulting
information model and the resulting data definition
language,
and
d) any
work to be undertaken needs to have a carefully defined
scope.
There was not, however, a strong consensus about the
achievability of
any or all of these efforts.
It is difficult to synthesize and summarize the discussions,
given the
lengthy dialog.
Many individuals held individual positions, but there seemed to
be at least
three locuses:
a) a new work should be
started, it is worthwhile and achievable
b) a new work should not be
started, while the desired result would
be
worthwhile, it is not achievable
c) some middle road.
Work in the short term on pulling together
the various
data models, i.e., SMI, SPPI, SMIng. Work on pulling
together the various information model efforts in the longer term.
At the end of the BOF, Bert Wijnen, IETF Area Director for
Operations and
Management stated that he believes he has
gotten the message of what the
participants want.
He does not yet know that a Working Group will be
chartered. It could be the work of an existing Working Group, a new
Working
Group, or not done at all.
The minutes are being posted to the NIM mailing list and the
discussion
will continue there, especially since
schedule conflicts between the
BOF and other meetings
made attendance impossible for several people who
expressed a desire to participate.
After the discussion on the list, the BOF Chairs and the Area
Directors
will confer to determine next steps.
A more lengthy set of minutes follows.
----------------------------------------------------------------------------
NIM BOF Summary
48th IETF
Pittsburgh, PA, USA
August 2,
2000
The Network Information Model Birds-of-a-Feather session met
on
Wednesday, August 2 at 9 AM during the 48th
IETF. The chairs of
the session were Jeff Case
(case@snmp.com) and Walter Weiss
(wweiss@ellacoya.com). The meeting was reported by Steve
Moulton.
Supplementary notes were taken by Glenn Waters
and Robert Moore.
The three sets of notes were compiled
by Jeff Case.
There is a mailing list for this topic at
nim@ops.ietf.org,
and subscriptions may be requested at
nim-request@ops.ietf.org
(subscribe nim). An
archive of the mailing list messages is
available at ftp://ops.ietf.org/pub/lists/nim*.
All slides presented during this session will be available
at
http://www.snmp.com/nimbof for at least the next 60 days,
pending
a permanent home as a part of the proceedings of
the 48th IETF.
There has been no attempt to reproduce the slides in these minutes.
1. Introductions and Agenda
The first agenda item was the usual
introductions and agenda
bashing,
moderated by Jeff Case. There were no objections to the
agenda as posted on the slides, which is summarized
below:
Introduction to the
Problem
Current Related Works
Requirements Document
Determine Interest
in Further Work
Charter Discussion
The goals of this BOF were covered.
They are to:
o introduce the potential work,
o assess interest,
and
o
to make a recommendation with respect to the chartering of a new
Working Group.
2. Introduction to the Problem: (Walter Weiss)
The second agenda item was the introduction
to the problem and
approach.
This was presented by Walter Weiss.
In addition to the points made on the problem
statement slide, the
following points
were made: There is a lot of duplication in
data structures that cross the various management
protocols and
methodologies.
NIM should not be just another way of doing things.
When the SMI came out, there was a lot of effort put
towards educating
the IETF community
on how to build these things. A similar educational
effort will probably be necessary if NIM is to be
successful.
The proposed approach is to use or specify a
language that
describes the attribute
and method relationships with enough detail
that a mechanical means for mapping those structures
to specific
protocols can be
supported. We need to determine the process for
defining and aligning various technology-specific
models to maximize
reuse and
consistency. We need to make sure there are
mechanical/algorithmic means for going to and from the
model to the
various
technology-specific data structures (MOFs, PIBs, MIBs, etc).
3. Discuss Current Related Works
The third agenda item was presentations on
related work in this space.
There is
a large body of related works available which can be used
as a basis upon which to build and to learn
from.
Two speakers had prepared presentations on this topic.
The first presentation (with slides) was made
by Andrea Westerinen
(andreaw@cisco.com) on extant models and languages.
She responded to questions after her presentation.
Question from the floor: What is the difference between CIM and UML?
Andrea: There
are similarities between all of the models. It is
possible to map between CIM
and UML. UML is the representation
that the DMTF uses.
The second presentation on related works was
made by
Juergen Schoenwaelder
(schoenw@ibr.cs.tu-bs.de). He described the
work being conducted in the SMIng project and related
work.
He responded to questions after his presentation.
Scott Hahn: What is the correlation between SMIng and XML.
Juergen: XML
can represent all of SMIng. XML can be used as a
meta-language.
4. Strawman Requirements Document
The fourth agenda item was a presentation on
a requirements strawman
(draft-durham-nim-requirements-00.txt) presented by David Durham
(david.durham@intel.com).
His presentation covered the following major points:
What is an info
model?
models key
concepts
classes
relationships between classes
protocol
independent
What is a data
model?
implementation specific
includes
protocol-specific optimizations
ideally
derived from an info model
Requirements for an
info model
class
naming
instance
identification NOT definable by info model
handled by each data model
must have
textual representation
associations, with multiplicity constraints
are represented as classes themselves
data
definition constraints
attribute bounds/enumerations
semantic constraints
read/write, optional/required
interdependencies between attributes
uniqueness of attributes
inheritance
single inheritance only?
single root?
extensible
data types
standard
combinations of classes and associations
methods
when to use a method vs. an attribute?
compliance: test whether a derived data model
complies with an information model
containment: class A contains class B
backward
compatibility: achieved via inheritance
David concluded his presentation with the
point that the requirements
document
still needs more work as it is "fairly controversial and largely
unfinished."
Several questions were posed after the presentation.
Andrea
Westerinen: Did you have any thoughts about what the
model might require that are
not addressed in the document?
David:
Yes. Scope is an appropriate discussion for the charter.
This is not in any way
addressed in this document.
Dan Romascanu:
Your last requirement was about compatibility.
What effects to you see this
having on existing work in MIB and PIB
space.
David: This is
not what the backward compatibility requirement is
talking about.
Lee Rafalow: Do
you have any ideas how this might help with
problems like reconciling
DiffServ & Core Policy, IPSP & Core Policy?
David: With
conventions for doing data models, incompatibilities
will be easier to
resolve. The hope is that this gives conventions
so that we can map the work to
various technologies.
Juergen
Schoenwaelder: Did I understand that it is a requirement to
have algorithmic
mappings?
David: yes.
Juergen: How
can these be done if the information model has no
instance identification?
Did I understand that you want to leave
out instance identification
because it is too complex?
David: Not
because it is too complex, but as it is already done in too
many different ways. You
have to address it, perhaps by providing
enough information in the
information model and be able to use
attributes to map to an
instance naming scheme. All you can get from
the information model is the
information to do the mapping, not
the mapping itself.
Jeff Case: We
need mechanisms to do mappings between the naming in
the information model and the
naming in various data models, but not
all the possible
mappings. We should do some, and leave the hooks
for others to map. It
will be controversial to say which are the
mandatory mappings.
David: All that
is currently stated is a set of requirements, not
automated mappings.
John Strassner:
I am trying to map NIM back to the original approach
which was to use a
language.
David: I never said to use a language.
John: (wants to
know how we go from a language to a information
model)
David: A
textual representation that can be mapped is important,
but a language is not
specified.
Keith
McCloghrie: In the more general context, to expect people to
use a common
information model across multiple data models, you have
to take away the reason to use
a specific data model. I believe
that the information model
needs to be able to create a particular
representation in the data
model as needed. In particular we have
the indexing problem.
You need to solve it in a way that is a
superset. The
information model must effectively have the duplicate
of two different things to do
this.
David: Yes. The requirements document punted on this.
Walter Weiss:
It is more feasible to come up with an overarching
representation for instance
identification that meets all of the
needs, or do you deal with
these issues at the mapping stage. If we
do the language and then the
mappings, either way we need to deal
with it. We have had bad
experiences with trying to do it on the
front side.
Keith
McCloghrie: This must be done on the back end. Otherwise you
will fail in this
effort.
5. Determine Interest in Further Work
Jeff Case moderated a discussion of four questions:
. Would having
such a work product be a "Good Thing" and a worthwhile
goal?
. To what
extent is there interest in using the result if produced
in our
lifetimes?
. Do you
believe that such a work product is sufficiently achievable
to be a
worthy undertaking?
. Is there a sufficient core of willing workers?
Both IETF Operations and Management Area
Directors, Bert Wijnen and
Randy Bush
joined the meeting in time for the discussion and to
gauge interest.
The first question,
Would having a network
information model and data definition
language that can be used with
algorithmic mapping to
technology-specific data
structures and thereby avoid having
duplication of effort be a
"Good Thing?"
generated multiple
questions and comments.
Lee Rafalow: The answer is yes, but the
question is wrong. The
proper
question is: Would an effort like this contribute to a tower
of Babel or fix it?
Andrea Westerinen: There is still the
question of whether this is a
language or a model. If the work product is a language, I don thing
we need another language. If the work
product is a model, then OK.
Randy Presuhn: Following up on that
comment, we need to be a little bit
clearer as to we are talking about meta-models under our data models,
or we are talking about modeling
language. Are we going to be
describing constraints so that we can algorithmically translate?
Walter Weiss: I would like to consider
Andrea's question. We have to
agree on a way to specify the model before we specify the model itself.
Andrea Westerinen: We need to agree on
the model and the scope of the
model. Do we use a language or a model?
Walter Weiss: This is a fair
question. We have to do both, otherwise
we don't really solve any problems. We don't
help folks who are
creating PIBS and
MIBS concurrently.
John Strassner: I am still struggling
to understand the link between
the
model and the language. Walter, you were focusing on defining the
mappings from an information model to a set
of data models.
Walter Weiss: If we are going to
contribute positively, we need some
set of tools. It is reasonable to assume those tools include a
model
and a language to translate to
the data models.
Jeff Case: The SMI is both a model and
data definition language that
is used
to express the model. It includes a set of important naming
conventions. It provides an example
where the model and the language
are
tightly coupled. It also shows that we have experience in designing
data models that can be used with multiple
management paradigms, protocol
designs, and implementation strategies in that the SMI and MIB was
originally designed for compatibility with
both SNMP (SNMPv1) and the
OSI-based
management protocol of the day, CMIP. We need to have
algorithmic mappings between the naming in the
information model and
the naming in
various data models.
John Strassner: Your answer and
Walter's answers help a lot but
raise
several other questions.
Randy Bush: The reason this is a
rathole is twofold. The language
constrains how we think. We design the language
to meet the needs of
we need to
express. We need to discuss what we need to express, and
then design the models and languages.
Dan Romascanu: Did you design the SMI then the language?
Jeff Case: When we did SGMP, all
information was named by a simple
octet string and there was no separation between the protocol and the
MIB. As we moved to SNMP, We were in a
world where all information was
named
by ASN.1 (CMIP, GDMO). We came together (see RFC1052), did the
two
independent parts, the MIB and
the protocol, and glued them together with
the SMI.
Dan Romascanu: There are three
requirements: model, language, and
mappings. The NIM work is absolutely
necessary.
Hilarie: I think part of the question
is whether or not this solves
enough
problems. I'm worried that this will force people to
get hung up on notation. I'd like to see more
examination of current
problems and
how this might help, rather than see a Working Group
set up.
Margaret: I think it would be a good
thing to have one language used
to
define data models for protocols. Don't we already have enough
information models already? Is there a
reason not to use a current
information model? Why are we not reusing an existing model?
Jeff Case: If there are nine models,
then that is evidence that the ninth
one met a need that the prior eight did not address. We need to do
good engineering and strike a balance -- if
there is something existing
that will
work, we should look at that work.
(floor): I think we should have a
Working Group to develop the
requirements, then one to develop the model.
Jeff Case: If there is something that
will work already out there,
we will
use that.
(floor): We need to determine if SMI,
CIM or something else or some
combination will meet the need.
Jeff Case: What I heard you say is that
you would favor a Working
Group that
looks at what the possibilities are, and only then look
at forming a new one.
(floor): I come at this from a a
historical perspective. It looks
like there is a trend towards behavior-based
modeling. Are we
looking at
state or behavior? Network information is not only how
things are put together but how they interact.
David Perkins: I've seen people reject
SMI for a simpler language,
and
reinvent SMI. I'd like to suggest that rather than trying to
develop a new language, we should take an
existing language and extend
it to
solve the list of requirements. Whether it is in this Working
Group or others, it should be done this
way.
(floor): Where are we going? Are we trying to develop techniques?
Jeff Case: We are trying to develop
rules for applying current models
to
network management and configuration. I see the same thing
happening that happened in the SMI. We
would have some rules and
structure
to build on, and then let them grow in time.
Bob Moore: You've been talking about
algorithmic mappings from the
information model into the various data models. Whenever I hear
algorithmic mapping, I pull back. My
experience is that when you use
algorithmic mapping to get from A to B, you get a lousy B. The only
way to get a reasonable output is to apply
human intelligence. When
mapping from one model to another, I am skeptical that algorithmic
mapping is what you want to use.
Jeff Case: I hear that as a yes on 1
and a doubtful on 3.
[see slide above
on "Questions to Ponder -ed].
Randy Presuhn: Discussions yesterday in
the Policy Working Group
revolved
around where various data models have been developed in
advance of an information model. The question
was raised on
whether these data
models should be dependent on an information model.
The consensus seemed to be no. Today seems
different. This would
be a
change in the way we are doing work.
Scott Lawrence: I think that bullet one
is yes, apple pie and
motherhood. Nearly all languages and modeling mechanisms that were
listed had as an explicit goal that they
would be able to encompass
all
previous languages. I think that they have failed and added to
the tower of Babel. If you are going
to have something better than
the
previous languages, you have to do something new. This means you
can't do algorithmic mapping.
Is it worth it to sacrifice going
backwards? If so, is it worth
transitioning to it? I don't think people will abandon existing
mechanisms.
Andy Bierman: I think it would be
difficult to produce a superset
information model that everyone would agree with using a bottom up
approach. One of the difficulties is
that there are concepts
(such as
access control in SNMPv3) that would not be easy to put
into a information model.
Jeff Case: Are these the right
questions to ask when considering
whether we should form a Working Group?
Randy Bush: Yes.
Joan Cucchiara: How does this translate
to protocol groups using this
model?
Jeff Case: The two protocols and data
models that I am most
familiar with
is COPS/SPPI/PIB and SNMP/SMI/MIB. Both support integers,
strings, pointers, and combinations thereof. If
there is another
data type, I don't
know what it is. Once an build an object oriented
system on top of these data types. Consequently,
I am not sure the
mappings are
impossible. They may be ugly or undesirable.
Keith McCloghrie: We need to be not too
ambitions here to effective
address
the problem. We need to narrow the scope enough that we can
get some algorithmic mappings.
(floor): Right now what I see is MIBs
going to last call that don't
even
compile. I'm am concerned that the process won't work
i.e., MIBs going to a model first.
John Strassner: Sure you can use
integers and such to map values, but
that does not really capture semantic dependencies and behaviors.
This is why you use an information
model. This is the real value here.
What is it you are trying to model in the information
model and what
are you trying to
produce with a language?
Ed Ellesson: Cannot answer the four
questions without first knowing
the
proposed scope of the effort.
Walter Weiss: The problem is that data
structures are being developed
in
parallel. How can we get a common set of structures across multiple
paradigms? How far do we go? Is
a picture enough? Do we want to
tackle algorithmic mapping? How broad do you want to go? We had
a
challenge in mapping from an
information model to a directory scheme.
They were not algorithmically mappable. If we go
down this route,
what process
facilitates the use of this? If we toss this to the
Working Groups, how do we help them use this?
Margaret: The scope must be defined in
two directions. Are we going
to
define the MIB-2 in this language?
Jeff Case: My opinion that MIB-1 did
two things. A reasonable set of
objects. An example on how to write a MIB. I'd like to repeat
this
process.
Margaret: A third axis: what do
we have to model. Do we model data?
Access control? Interactions between
data?
Jeff Case: We want to keep our scope as
limited as possible and allow
other
groups to build off of it.
(floor): I agree with not accentuating
algorithmic generation. It
is
going to be important in the Working Group charter to say not only
will this be a greatest hits album, but will
we provide an
institution for
guidance for Working Groups.
Jeff Case: I believe the proposed
Working Group shoudl create a model
and a base of expertise for other Working Groups to use.
David Perkins: "naming" versus
"identification" Different management
protocols have fundamental differences of
granularity. In SNMP you can
access individual attributes but you can't define actions. In other
models, the opposite is true. I'd love
to see a unified mapping language.
If
we can do a Working Group that can say, can you guys add this and
that to your modeling languages (to enable
this), I would sign up for
that.
MIB2 has a model of what internet nodes are
all about. I think this
needs to be
revisited.
David Durham: We need to specify a
common way to specify things,
but not
think about automatically generating things from the result.
We need to take baby steps to understand what we are
tying to
accomplish.
Jeff Case: What I hear is yes on the 4
questions, with tweaking:
helpful
hints, not mandates and edicts. That is a user guide, not a
law.
David Durham: Yes.
Lee Rafalow: I am a liaison between
POLICY and IPSP. I spend a
significant time understanding policy, CIM, and IPSP. I would have
to participate here unwillingly.
Jeff Case: Your answers would be y y n n
Lee Rafalow: Yes, but question 1 is the wrong question.
Andy Bierman: I don't think a top down
approach is going to
satisfy the
various constituencies. I am most interested in SNMP.
The problems that SNMP is trying to solve would be
constraints on
this information
model, and someone who is not doing SNMP would
not want these constraints. Let's avoid the sofa
bed problem
(not a good sofa and not
a good bed).
The MIB is the contract between the device
and network management
station
developers. I am in favor of Juergen's approach of
expanding the SMI, but not this Working Group.
JS: (note takers disagree whether Jon Saperia
or Juergen Schoenwaelder)
I have a
bunch of concerns.
1) With finite human
resources, I don't know if this is more
important
than the other things we are working on.
2) Even with enough resources,
not sure it can be done.
3) I am not sure if this work
will help the various Working Groups;
it may make
them harder not easier: n --> n+1, n --> 1
(floor): Having to worry about tying
this stuff together, this would
give
us one point to start, rather than 15 or so.
Walter Weiss: I've heard two themes.
1) Start out with
universal meta data definitions. It is not clear
how easily these could be
mapped so it is not clear this would be
constructive at all.
2) I've heard
that "yes we have a problem with parallel definition"
but we should bottom-up focus
on 80% of the work.
What we had suggested
originally, if we take an existing language that
can be mapped to a subset of
protocols, this resolved the problem with
all of the parallel efforts
taking place. There was some pushback
saying "I've got to do this
anyway". There was also some saying
"I'd rather use the
incremental approach", and accomplish a reasonable
cross-section in that
environment.
Keith McCloghrie: Certainly it is
possible to do some merging of
SPPI
and SMI (and SPPI is trying to do that at the moment, so we
don't need another Working Group to do that).
The idea is to use
the SMIng and
extend it. If we go beyond those potential three
things, we go too far.
David Harrington: I would like to see
one common data model for AAA
and
SNMP for the O&M area.
The BOF Chairs attempted to synthesize and
summarize discussions but
it was
difficult to do so, given the lengthy dialog.
Many individuals held individual positions,
but there seemed to be
three
locuses:
a) a
new work should be started, it is worthwhile and achievable
b) a new work should not be
started, while the desired result would
be
worthwhile, it is not achievable
c) some middle road.
Work in the short term on pulling together
the various
data models, i.e., SMI, SPPI, SMIng. Work on pulling
together the various information model efforts in the longer term.
We are going to have to confer after the BOF
is over to see where we
go from
there. We invite additional thoughts and comments to the
mailing list.
Andrea Westerinen: would like to try
get have the scope constrained
before
we continue.
There was a strong consensus regarding the
need for a carefully defined
scope.
In the additional time available, the BOF participants explored further.
The group again considered the question, To
what extent are you in favor
of
saying: (reference to question 1)
We are not going to try to
pull these together - we are not going to
start any new work in this
area.
(there was not much support for
this proposal).
The opposite of the question was
considered: Is it correct that we do
not want to do nothing? i.e., we would like to see
some forward progress
on pulling some
of the duplicated effort together?
The consensus appears to be yes.
Is there an interest in general in starting
new efforts or allowing
ongoing
efforts to bring together the work in SMI and SPPI?
The consensus appears to be yes, but no so
firm.
Is there interest in pulling some of the data
models together to
convergence?
Several dissenting votes, consensus appears to be yes.
Is there interest to put an information model
at the highest level
and the data
models at the lowest levels together. The
consensus appears to be no, with several
assents.
These straw polls generated several more questions and comments.
Andy Bierman: We should charter a
Working Group for SMIng, based on
Juergen's work in the NMRG.
Dan Romascanu: Would SMIng converge both SMI and SPPI?
Jeff Case: That is the intention.
I think we should rename it to
something more technology neutral.
Randy Presuhn: What is the planned
migration strategy from
migration of
MIBs to the new syntax?
Jeff Case: We don't know.
Keith McCloghrie: What are the other
Working Groups going to do with
a new
SMI? We should keep the name.
Bert Wijnen: Many of these questions need to be asked on the mailing list.
David Harrington: The SNMPv3 Working
Group has a strong consensus that
we
do not want to use the name SMIng if it contributes to a perception of
instability.
6. Charter Discussion:
The last item of the agenda was the charter
discussion. A lot of
this
happened under the previous item.
Bert Wijnen: believes he has got the
message of what this group wants.
He
does not yet know that a Working Group will be chartered. It could
be the work of an existing Working Group, a
new Working Group, or not
done at
all. The BOF was scheduled in conflict with some other key
groups and we should have their input on the
mailing list.
7. Wrapup:
The minutes will be posted to the NIM mailing
list and the discussion
will continue
there, especially since schedule conflicts made attendance
impossible for several people who expressed a desire
to participate.
After the discussion on the list, the BOF
Chairs and the Area Directors
will
confer to determine next steps.
Jeff Case: Thanks to the note takers,
presenters, participants, and
Walter
Weiss.