[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Scope of NIM
There are two related, but distinct dimensions of "scope"
that have tended to get run together in these NIM discussions:
1. Data modeling / data representation: MIBs, PIBs, CORBA,
LDAP, GDMO, etc.
2. Domain being modeled: Diffserv, Intserv, IPsec, storage,
I think that most of the early discussions of "scope" were
centered on (2) - for example, Andrea's questions about the
scope of what NIM would be modeling. This is also what
people meant when they talked about helping different WGs
model common elements in a common way. (It's clear that
this is what they meant because they contrasted this goal
with what happened with SNMP: many WGs, all using SMI as
their data representation, came up with divergent ways of
modeling the same things.)
Recently, though, much of the discussion has shifted
to (1), where "scope" now means which data modeling
technologies will be unified by NIM. We haven't left
(2) behind entirely, though, because as several people
(starting with Randy Bush) have observed, what we model
is not independent of the technology we use for modeling
I think that (1) and (2) are both legitimate scoping
questions, which need to be discussed. We should be
clear, though, which one we're discussing at any point.
On a related note, I was surprised when Walter said:
At the last IETF, there was a strong desire to
see SMI and SPPI converge. If this happens, we
still have to question where the data
structures are developed that can be used
commonly across both COPS and SNMP.
I think the question of where the common MIB / PIB
data structures would get defined is one of the few
easy questions in this whole discussion. Given the
(relatively) long-standing practice of having MIBs
defined in the subject-matter WGs, and the more recent
practice of handling PIB definitions in the same way,
it's obvious where the common MIB / PIB structures
would be defined: in the subject-matter WGs. The
question becomes hard only if we slide over from
(1) (convergence of MIBs & PIBs for a given domain)
into (2) (convergence of MIB / PIB definitions
across multiple domains).
IBM Networking Software
"Andrea Westerinen" <firstname.lastname@example.org>@ops.ietf.org on 08/21/2000 07:06:55
Sent by: email@example.com
To: "Weiss, Walter" <firstname.lastname@example.org>, "'Tom Scott'"
Subject: RE: Scope of NIM
Walter, I agree and support your summary. It is very well articulated. I
would just like to clarify a few sentences ...
You state "we [can] expand the scope of applicability to include CORBA and
policy framework. However, this comes at the expense of less practical
applicability to MIBs and PIBs". Regarding the words "less practical
applicability", this might be better stated as "less straightforward
applicability", and is certainly mitigated by mapping algorithms and
guidelines. Regarding the words "scope of applicability", I would prefer
to say that "we expand the scope of applicability to the network, its
services, devices and policy, including the work of OMG, ITU, DMTF and
other standards bodies." Specifically, CORBA does not address a network
information model (but pieces of the problem), and is not the only
Obviously, for an initial scope, I would prefer a much more concrete
description and set of goals than to model "the network". :-)
From: Weiss, Walter [mailto:email@example.com]
Sent: Monday, August 21, 2000 11:23 AM
To: 'Tom Scott'; Andrea Westerinen; 'firstname.lastname@example.org'
Subject: Scope of NIM
Tom and Andrea,
Both your insights are well founded. There is clearly a scope issue that
needs further consideration. The interest around NIM is driven by the
desire to develop a single model that can be applied or mapped to various
protocols. If the mappings don't exist or are not used, then we would be
building a tower of babel by creating yet another set of data
definitions/interfaces. However, even if only two protocols derived from
the model, the net effect on the number of distinct data
definitions/interfaces would be an n-1 instead of n+1.
With that in mind, I would like to contrast two alternatives for
developing an information model. At the last IETF, there was a strong
desire to see SMI and SPPI converge. If this happens, we still have to
question where the data structures are developed that can be used commonly
across both COPS and SNMP. If PIBs are still independently developed from
MIBs, the benefits of consistent management of devices across management
protocols is greatly deminished. If an effort was undertaken, it would not
only be applicable to SNMP and COPS, but also to other data-centric
protocols such as LDAP. To develope a data-centric information model does
not go as broadly as we had considered in the requirements and the
language issues would already be taken care of elsewhere. The main issue
would be how to meet the modeling needs of these data centric protocols.
For example, how are data structures defined to meet the needs of both
device configuration management and higher level policy management? If
this question can be addressed to the satisfaction of the MIB and PIB
folks, we have clearly achieved an net gain (n-1).
The second alternative for an information model is take this one level
higher. By defining not only data structures but also methods and fully
specified associations (with independent properties), we expand the scope
of applicability to include CORBA and policy framework. However, this
comes at the expense of less practical applicability to MIBs and PIBs, as
was readily apparent from the discussions at the NIM BOF. Further, this
work would be dependent on the specification of a new or existing language
for defining this high-level information model. This second alternative
also leads to speculation about this works effect on the landscape. Would
the net effect be an n-1, n, or n+1? This question must be answered to
everyone's satisfaction before broad support can be expected.
If we are going to make progress, I would like to keep the question of
scope to be grounded on the question of net effect. If a positive effect
can not be demonstrated, this work will not and should not proceed.