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.