Subject: snmpconf BCP re: policy layering

From: Steve Waldbusser <[email-masked]>
Date: Fri, 15 Jun 2001 08:32:07 -0700

I have some general comments and questions about the policy layering
taxonomy in the BCP.

>    7.2.  Conceptual Layering
>
>    In order to present the principles of policy based management with
>    SNMP, we will create a MIB Module called the Building Heating
>    Ventilation and Air Conditioning (HVAC) MIB Module. This allows the
>    discussion to focus on the new principles as opposed to a specific
>    area of technology. Note that while the focus of this discussion is
>    on configuration, the abstractions discussed in this section could
>    equally apply to fault, performance, accounting or security objects.
>
>    Instance-Specific
>
>    Instance-specific information refers to values associated with a
>    specific instance in a managed element. One example would be the
>    number of octets that were received on a particular interface,
>    ifInOctets. In our example MIB Module, we will have fan and
>    temperature settings for every control panel in the building. Imagine
>    how many there would be in a 50-story office building or multi-acre
>    office park. Network operators have a similar problem, in all of the
>    parameters for the many routers and the interfaces they contain.
>    Each interface will have an ever increasing number of values that
>    must be configured to deliver specialized services such as
>    Differentiated Services.
>
>    Mechanism-Specific
>
>    The first layer of abstraction above the familiar instance-specific

Nothing in this section actually says that mechanism-specific MIB
objects are instance-independent (i.e. a characteristic of being a layer
above instance-specific is to be instance-independent). If that's what
is meant it should be stated here.

Assuming that's what is meant, however, I don't think that should be a 
characteristic of the mechanism-specific layer. The mechanism,
implementation, domain, and service layers provide *abstraction* as you
move through the layers. However, instance-independence provides
simplification by reducing the number of instances but it doesn't
provide abstraction.

For example, you could say that "ifInErrors" is a mechanism-independent
abstraction of:
  Ethernet
       dot3StatsAlignmentErrors, dot3StatsFCSErrors, 
       dot3StatsFrameTooLongs, ...
  Token Ring
       dot5StatsLineErrors, dot5StatsBurstErrors, 
       dot5StatsACErrors, ...
  etc.

Using ifInErrors gives me the benefits of abstraction in that I don't
need to understand the details of the mechanism (token ring or
ethernet).

Turning to instance-dependence, an instance-specific usage would be to
request the "ifInErrors on interfaces #7 and #11" and an
instance-independent usage would be to request the "ifInErrors on all
trunk ports".

Putting these together, I can have 4 types of statements:
  instance-specific/mechanism-specific:
      dot3StatsAlignmentErrors.7
  instance-specific/mechanism-independent:
      ifInErrors.7
  instance-independent/mechanism-specific:
      dot3StatsAlignmentErrors on all trunk ports
  instance-independent/mechanism-independent:
      ifInErrors on all trunk ports

If you place instance-independence at the bottom of the
abstraction-layer stack, first of all it doesn't fit because
instance-independence isn't an abstraction layer and second of all it
doesn't take into account the instance-specific/mechanism-independent
case above.

If a typical instance looks like dot3StatsAlignmentErrors.7,
instance-independence messes around with the stuff to the right of the
dot (.) and abstraction-layers mess around with the stuff to the left of
the dot.

Also, note that the abstraction layer is an attribute of a MIB object
(ifInErrors vs. dot3StatsAlignmentErrors) while instance-independence is
not an attribute of the MIB object definition, but of how that object is
used. This is true even in the HVAC MIB which, while it makes it
*easier* to achieve instance-independence, is only instance-independent
if it is used that way (I can still use the HVAC MIB in an
instance-specific way).

I'd suggest that the issue of instance-dependence be separated from the
issue of the abstraction layer. A management operation is then described
as being instance-independent or not and as being at a particular layer.
So I'd take instance-specific out of the hierarchy and have it described
right before the hierarchy.

>    level is called "mechanism-specific". This is the level that contains
>    the defaults that would be used to assign values to instance-specific
>    objects.

I'm not sure why this ties mechanism-specific to the issue of defaults.
"Defaults" isn't really an abstraction mechanism. The next paragraph
really says it better. I think that the discussion of defaults should be
removed from this section to keep the focus on the abstraction.

>    A "mechanism" is a specific way to realize a function. For example,
>    in the area of routing, BGP has a number of mechanisms that are used
>    to realize specific behavior. As a result, there are many parameters
>    that apply specifically to BGP and its associated mechanisms that it
>    uses to accomplish it's routing task such as time-out values etc.,
>    that BGP uses to accomplish its routing task.
>
>    MIB objects that are mechanism-specific are the defaults used for
>    instance-specific MIB object creation or modification. They are the
>    defaults for standard instance-specific MIB objects when used in an
>    SNMP-based policy system. In our HVAC example, we have several
>    mechanisms that are used in the standard MIB module to control how
>    fast a fan is to turn and what position a switch is to be in for
>    heating or cooling.
>
>    Mechanisms have on additional attribute that distinguishes them. They
>    are technologies defined in standards that are used within a
>    particular domain as in our routing example. Mechanism-specific MIB
>    Objects then, are a layer of abstraction above standards-based
>    instance-specific MIB objects.

I think there's a typo somewhere. The 2nd sentence says that mechanisms
are defined in standards (ergo standards are mechanism-specific,
right?). Then the 3rd sentence says that mechanism-specific is a layer
above standards-based. Where did I go wrong?

Also, I think it's dangerous to typecast standards-based objects into a
particular architectural category because as soon as a standard is
written including higher-level objects then this will be wrong.

>    Implementation-Specific
>
>    Vendors often add special capabilities to standards as a way of
>    meeting special customer requirements or differentiating themselves
>    from competitors.  Implementation-Specific MIB objects have the same
>    properties as mechanism-specific ones except they have been created
>    as abstractions for vendor created instance-specific MIB objects.
>
>    These special capabilities are often a result of the implementation
>    approach that a vendor has used for the product, which is the reason
>    for the term "implementation-specific". In our HVAC example, some
>    vendors might extend the standard to include features that
>    distinguish their products from their competition. In our example MIB
>    module, the system is a sophisticated one and allows for the control
>    of the humidity, which is not part of the HVAC standard MIB Module
>    and as such there would be no mechanism-specific MIB objects for
>    humidity.
>
>    In summary, implementation and mechanism specific MIB objects occupy
>    the same level of abstraction in our hierarchy. The only difference
>    is that mechanism-specific MIB Objects are defined in a standards
>    body, while implementation-specific objects are defined by vendors in
>    the same way that vendors define their extensions today.

This surprised me a bit. I would have thought that
implementation-specific was the lowest layer of abstraction (i.e. vendor
MIBs). The mechanism-specific layer (today's standard MIBs) abstracts
out implementation details but leaves mechanism details. The
domain-specific layer in turn abstracts out mechanism-specific details
but leaves domain-specific details.

>    Higher Levels of Abstraction
>
>    If the world consisted of only of MIB and protocol experts, the
>    abstractions described above would be sufficient. They enable the
>    efficient transfer of information from management systems to managed
>    devices. The fact is that many people who know nothing about the
>    protocol details need to use systems that manage SNMP-based
>    configuration data that know nothing about the protocol details.
>    There are vendor and model differences that make the addition of two
>    layers above the mechanism and implementation-specific layer helpful.
>    The higher levels of abstraction that are defined next help achieve
>    some important operational goals and make it possible to write better
>    management software. Here are some of benefits for organizing SNMP-
>    based information into higher levels of abstraction:
>
>         1. Abstract the details of the differences in technology away
>         from the users. This is a common principle in
>         programming. The user of a service should not have to know
>         the details of how the service is implemented. OSPF and BGP
>         are both routing protocols but have different "knobs". If you
>         want to add a new system to the network today, you must have
>         an expert in both if you use both technologies. Different
>         implementations of WEB servers have different "knobs". To
>         change a configuration or add a new service to each, you need
>         a person who knows the individual knobs. A solution to this
>         is to write software that abstracts above this level.
>
>         2. Abstract the differences from one vendor to another. Even
>         when standard technologies are implemented, vendors will have
>         variations. In a multi-vendor environment this means that not
>         only do you require technology experts, but you have to have
>         experts who know the differences in the knobs for each
>         technology for each vendor. In the case of SNMP, these knobs
>         are MIB Objects.
>
>    Domain-Specific
>
>    A useful way to abstract information above that which is exposed in
>    instance-specific,implementation or mechanism-specific MIB Objects is
>    at the level of "domain'.
>
>    A domain is a short-hand way of referring to all mechanisms used for
>    a common task or provisioning of a particular technology.. In the
>    routing examples we have been using, BGP would be one domain that
>    contains many mechanisms. This is also true for OSPF. The same is

I think many people would have thought that routing was the domain and
BGP was the mechanism. Could we see how some technologies fit into the
hierarchy to make sure that it works? We might need to think harder
about the names of these layers and the number of layers. An example
would also help my understanding of the services layer below which I'm 
also having a hard time visualizing.

>    true in the area of Quality of Service, there are many areas of
>    technology (domains) that could be used to deliver quality of
>    service. Differentiated Services or 802.1p are two examples that have
>    very different mechanisms. Our HVAC MIB module has a single knob for
>    the mechanism that is used to control the climate inside a building.
>
>    In our case, the desired temperature is the knob which causes fan
>    speed to change.  It is possible to imagine a very different set of
>    technology that instead of using fans, controlled exposure of solar
>    cells to change the temperature. The SNMP infrastructure gives us a
>    number of convenient ways to reference domains though the mapping is
>    not always perfect. These handles include the base OID of a MIB
>    Module or the tables in a MIB Module.
>
>    Since the OIDs are not necessarily contiguous, several of them may be
>    used to specify a domain. In the future IANA could become a registry
>    for such identifiers.

Why will we need to reference domains? 

This sounds a lot like ifSpecific which turned out to be a poor idea.

>
>    The Services Layer
>
>    Some management applications may find it helpful to present one layer
>    of abstraction above the domain level: services. At this layer we no
>    longer refer to specific technologies such as BGP, OSPF, or
>    Differentiated Services. We refer to routing or Quality of Service.
>    This is the layer that many business operate at. One example is that
>    they sell Web or Name services without referencing the specific
>    technology domain that will be used to realize the service. For
>    example, n most circumstances they, will certainly not reference the
>    mechanisms used to realize the Web Services.

Regards,
Steve

Steve

---

From: Jon Saperia <[email-masked]>
Date: Tue, 19 Jun 2001 08:20:21 -0400

Comments inline.
> is meant it should be stated here.

Thanks, I re-read this section and it seemed quite clear that instance 
independence was explicit in that section. That said, I am happy to modify the 
introductory sentence in that section from:

"In summary, implementation and mechanism specific MIB objects occupy the same 
level of abstraction in our hierarchy."

to:

"In summary, implementation and mechanism specific MIB objects occupy the same 
level of abstraction in our hierarchy and are independent of any specific 
instance in the device."
> simplification by reducing the number of instances but it doesn't

It is at the bottom of the 'abstraction' chain and is presented for 
completeness - it is part of the hierarchy. In a sense the lowest level beyond 
which (at the present time) we can not abstract further. The dictionary uses 
for it's first definition of abstract,

   1 a : disassociated from any specific instance <abstract entity> 

This is what was on my mind when I started this (now nearly two years ago).

> need to understand the details of the mechanism (token ring or

I think this proposal mixes two concepts that should be separate. What you 
propose and is a great idea for MIB writers is what I would sometimes call 
aggregate objects. In the example above we are aggregating on an interface all 
errors for a particular media type then aggregating it further to a single MIB 
Object - an aggregate object as well that is for the entire machine which is 
the 'total' of all the instances. The second concept, and the one we have 
focused on in this work is the abstraction part of configuration parameters 
which implies a sameness not required of your counter aggregation example. 
That said we do not close the door to the association of aggregates such as 
you propose with mechanisms. In fact this is what I expect will happen when 
people start doing service level reporting using SNMPCONF.

> right before the hierarchy.

Please see my points above about why I kept instance-dependence as part of the 
layering. It is the bottom. Please also see the point about the dangers of 
mixing non-like things. While such aggregations may be quite helpful (e.g., 
all errors for all media types for all instances controlled by a policy), such 
aggregations while convenience may not always be meaningful.
> but leaves domain-specific details.

Implementation specific is to private vendor extension as mechanism-specific 
is to standards body defined.
> >    mechanisms used to realize the Web Services.

Thanks,
/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Jun 2001 09:58:11 -0400

It seems to me that Steve has a useful point here.  There is something 
different between the relationships:
1) instance specific vs instance independent
2) mechanism specific vs mechanism independent

The later is clearly a "generalization" relationship, elements of an 
abstraction hierarchy.
The former is not.  instance independent is not (in my mind) an abstraction 
of instance dependent.  Even if we assume (which I think most of us do) 
that what we are talking about in (1) is the difference between 
descriptions of things designed to be instantiated as specific instances 
and descriptions of things in more general terms, the generalization is not 
a generalization of "instance".  It is actually the addition of other 
concepts like role or technology, not an abstraction.

So, while I do not think that instance specific is orthogonal to the 
abstraction hierarchy, it does not seem to me to be the same "kind" of 
notion as the abstraction hierarchy.

Yours,
Joel M. Halpern

PS: One of the argument Steve and I had privately was whether you could 
have instance specific information that was otherwise higher on the 
abstraction hierarchy.  While I have think that the co0ncept may be 
inapplicable at the top of the abstraction hierarchy, it does not seem to 
me to be theoretically impossible to apply it at some middle levels.  In 
particular, prohibiting such cases by design seems excessive.  Rather, I 
would think that we should talk about instance specific as a separate 
concept, which is currently only known to apply to mechanism and 
implementation specific constructs.

---

From: Steve Waldbusser <[email-masked]>
Date: Tue, 19 Jun 2001 07:39:46 -0700

> level of abstraction in our hierarchy and are independent of any specific

Good, thanks.

>    1 a : disassociated from any specific instance <abstract entity>

But there is really a difference between instance-independence as a
technique for simplification and abstraction as a technique for
simplification. For example, in your Section entitled "Higher Layers of
Abstraction" you describe 2 benefits of abstraction (abstracting
technology differences away from users and abstracting vendor
differences away from users). Instance-independence achieves neither of
these benefits.

> people start doing service level reporting using SNMPCONF.

ifInErrors is an example of mechanism-independent abstraction. It may
also be an aggregation, but that doesn't reduce it's usefulness as an
abstraction example in this case.

Please reconsider the following considering ifInErrors as an example of

> is to standards body defined.

Agreed. But you can plug these together into a heirarchy.
Standards-bodies have been applying implementation-independence
abstraction to vendor-specific stuff. In turn, this mechanism-specific
output of the standards bodies can be abstracted further into a
mechanism-independent form.

---

From: Jon Saperia <[email-masked]>
Date: Wed, 20 Jun 2001 09:42:46 -0400

The note from Joel along with Steve's follow-up has helped me to
understand the points better and I have some specific comments that
follow his. Part of the problem we have is to select a terminology that
is general enough to be helpful to most and precise enough to be
meaningful. That said here are some general points.

        1. The purpose of the taxonomy as I have proposed it with most
        recent modifications, the addition of a higher level based on
        Joel's earlier comments, is to help the general community see a
        simple hierarchy. This is a useful discussion to have and one I
        would have preferred prior to just entering last call - but this
        is why we have last call:-).

        2. It is not the intent of the taxonomy to define an object
        model with all possible object/class relationships, though I
        have done so in my own work. I believe that task to be outside
        the scope of this working group. A taxonomy is a general model
        and as such it may contain several components, more on this
        later.

	3. While I like this conversation, I am not sure what, if any,
	edits are needed or appropriate since the taxonomy is not
	intended to be an object model. It is a description of general
	principals to help people think about different layers and how
	they might build policy-based configuration systems that use
	SNMP technology. I proposed one clarification in the earlier
	message in response to Steve that he liked. Other concise,
	specific proposals are welcome.

> 2) mechanism specific vs mechanism independent

Joel, though we use different terms for this, I agree (and did in my
previous note) that there were two separate concepts - Steve obviously
agrees as well. What is not clear to me is do they make a difference in
our current discussion.

> implementation specific constructs.

Now for some details even thought I think they are at a level of detail
far to great to be useful to most people who will read the
document. Again specific concise word change proposals to help clarity
are welcome. After this section, I will make some additional comments on
what Steve put forward in his instance/mechanism examples.

Joel's use of generalization is consistent with my use of it. That is in
an OO language, a class can 'extend' another class, etc.  In this sense,
mechanisms might be generalizations of domains. A domain such as
diffserv might use WRED or WFQ parameters. I use this as an example for
generalization, since it is the clearest I think in our 'hierarchy'
diagram.

It is not mandatory that a model have the same relationships which
brings me to the terms that I think are problematic:

       Association 
       Aggregation
       Composition

These are the terms that may help us get a handle on what is going on
with the instance-dependent vs. independent discussion. For this
discussion, I have used a Meilir Page-Jones book on OO design that I
reference when doing this work. There are alternatives and we could
debate them endlessly (but not on this email list). Here is my view of
how our layers fit.

       It is possible to have whole/part associations of several
       types. The approach I use has two, aggregation and
       composition. An aggregation is used to describe a component
       object. Generally speaking, and aggregation is said to be
       homeomeric. That is, constituents of the aggregate will tend to be
       of the same class.  Instance-specific objects created from a
       'template/or default' mechanism-specific value are almost
       certainly going to be of the same class. 

       A composition, on the other hand is not necessarily
       homeomeric. One such possible relationship in our
       hierarchy/taxonomy is between mechanism-specific objects and
       domains. It will not necessarily be the case that all objects
       that combine together to form the definition of domain such as
       diffserv or BGP will be instantiated from the same class. I might
       create separate peer group and path attribute classes in my
       implementation, or separate classes for meters and markers in the
       case of diffserv.

So I do agree that there is a difference between what I call a template
object, generally found at the implementation/mechanism level of
abstraction that is independent of a specific instance (it is after all
a template/default) and an object that is instance-specific such as
bgpPeerConnectRetryInterval.foo (where foo is the instance).

With this as background, I think we can go back to what I think is
Steve's most important point. Note that his examples were counters and
it makes more sense to perform aggregation in this context, that is why

> >       dot3StatsAlignmentErrors.7

I think we have this covered pretty well and there is not issue here.

> >   instance-specific/mechanism-independent:

I think the above is an important distinction, but once again not sure
if it relates directly to the hierarchy discussion in the BCP. I had a
lot more detail about 1 year ago on this that many of you read and it
was suggested that I remove it. We might consider adding a paragraph to
deal with this type of composition. I say composition becasue
ifInErrors.7 is comprised of objects that will almost certainly have
been instantiated from different classes. This is interesting but not
what we focused on when dealing with configuration. I believe it is
possible to define relationships with these counter compositions. Indeed
they are essential to doing SLA work and even basic accounting. 

Notice that what we are discussing here are not more or different levels
of the hierarchy, just different relationships. 

> >       dot3StatsAlignmentErrors on all trunk ports

Is a trunk a mechanism?

> >       ifInErrors on all trunk ports

We have to answer the first question first :-)

In summary, I agree with some of the distinctions and they are
valuable. The question is how relevant/necessary are they for the
taxonomy. If you feel they are essential, then I would welcome some text
to add that is more or less consistent with what we have. I say
consistent because I do not see anything that can not fit with the terms
in the BCP, we may need some expansion.

Thanks,
/jon
--

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 21 Jun 2001 17:51:32 -0700

> help the general community see a simple hierarchy.

Yes, I see your motivation behind a simple hierarchy. And I *do* think
that a hierarchical relationship exists between the implementation,
mechanism, domain and service-level abstraction layers. I just don't
think that the concept of instance-independence fits into that
hierarchical relationship.

A side note: Is this intended as a learning tool? An architecture for
policy? *The* architecture?

> agrees as well. What is not clear to me is do they make a difference in

My suggestion is to introduce the concept of instance-independence and
then seperately introduce the abstraction hierarchy that implementation,
mechanism, domain and service-level form. In other words, 2 concepts: 
1) instance-independence
2) An abstraction hierarchy

These would be peers, alongside the other concepts in section 7 such as
capabilities, capacity, and conflict resulution.

[...]

> I deferred discussing his points untilnow: He wrote:

The important part of my example is that the dot3Stats variables are
dependent on a particular technology/mechanism and require understanding
of that mechanism while ifInErrors is independent of a particular
technology/mechanism and doesn't require understanding of the specific
underlying mechanism. The fact that the ifInErrors happens to be
derivable by simple addition of the dot3Stats variables is just a
coincidence.

> they are essential to doing SLA work and even basic accounting.

In this case I'm just focusing on the fact that ifInErrors is an
abstraction of various mechanism-specific error counters for ethernet,
token ring, T1, etc.

> > >       dot3StatsAlignmentErrors on all trunk ports

No, ethernet is the mechanism and thus this is mechanism-specific. "all
trunk ports" is the rule that achieves instance-independence.

> in the BCP, we may need some expansion.

Here's some other examples of mechanism-independence that don't bring up
the aggregation issue:
1) ipRouteMetric1 is a mechanism-independent abstraction the primary
routing metric for a variety of routing protocols. 2) The
hrPartitionTable as a mechanism-independent abstraction of FAT, HFS,
NFS, NTFS, etc. (this could be argued to be an issue of
vendor/implementation dependence too). The hrMIB has several other
examples.

Regards,
Steve

---

From: John Schnizlein <[email-masked]>
Date: Thu, 21 Jun 2001 22:46:05 -0400

Your side note is a very profound set of questions.
It brings to mind the AD's question of whether the O-O theory and
Policy networking concepts are sufficiently widely practiced to 
warrant the designation "Best Current Practice".

John
At 08:51 PM 6/21/2001, Steve Waldbusser wrote:

>A side note: Is this intended as a learning tool? 
>An architecture for policy? 
>*The* architecture?

---

From: Jon Saperia <[email-masked]>
Date: Fri, 22 Jun 2001 07:55:34 -0400

> warrant the designation "Best Current Practice".

John, you will note that the BCP makes no mention of OO theory, simple 
layering yes. My OO comments were in explanatory email. The context is what I 
said and is Steve's first item in the side note. The taxonomy was created to 
help people understand some general principals for doing this work with SNMP - 
a learning tool for application of the technology, consistent with other BCPs. 
The reference language recently posted that is to be incorporated into the 
policy module underscores that this is a useful set of terms. It is how I 
would go about building a system to do these functions, if I were using MIB 
objects.

/jon

Thanks,
/jon
--

---

From: Jon Saperia <[email-masked]>
Date: Fri, 22 Jun 2001 08:07:45 -0400

Steve,

I think the distinctions are interesting and could be helpful for some, but I 
am not convinced that a real expansion of the text to as another dimension as 
you suggest below is all that helpful. What we could do is add a paragraph 
into the section that talks about some of these ideas. If you would like to 
propose such a paragraph of a few sentences, I would be happy work to fit it 
into the section of the BCP we are discussing.
/jon

Thanks,
/jon
--

---

From: "Wayne F. Tackabury" <[email-masked]>
Date: Fri, 22 Jun 2001 09:00:21 -0400

>hierarchical relationship.

It seems to me like an inevitable continuity of the hierarchical 
distinctions afforded by the abstraction.  To me, at some level, there has 
to be a placeholder for policy distinctions which are brought about by the 
nature of *specific* deployment by a customer, as opposed to those based on 
the nature of the product offering (implementation), selected technology or 
chosen RFC wxyz approach (mechanism), and generalized area of network 
service focus (domain).  Without the notion of "instance specific" policy 
design considerations, the model feels profoundly incomplete at its lowest 
layer.

>policy? *The* architecture?

To be honest, I struggled with that for awhile in my initial reaction to 
the BCP.  Going forward, in the way I've discussed the most basic realistic 
points of how to organize and deploy policy-based configuration (both 
within SNMPConf's technologies and outside), without some sort of reference 
model like this, I've found one cannot engage in meaningful 
conversation.  There is is, a *reference model*, without any of the more 
specific constructs or object models (and avoiding conflict with same) as 
offered by the likes of DEN and the DMTF.

Regards,
Wayne

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 28 Jun 2001 01:05:51 -0700

Wayne,

  I'm not suggesting that we take instance-dependence out of the
model, I'm suggesting that we take it out of the *hierarchy*. In
effect the model becomes two-dimensional:

                           instance-specific    instance-independent
                        |---------------------|----------------------|
implementation-specific |                     |                      |
                        |---------------------|----------------------|
mechanism-specific      |                     |                      |
                        |---------------------|----------------------|
domain-specific         |                     |                      |
                        |---------------------|----------------------|
service-specific        |                     |                      |
                        |---------------------|----------------------|

Some rationale:

o  There is something different between the relationships:
   1) instance specific vs instance independent
   2) mechanism specific vs mechanism independent

   In other words, the horizontal and vertical axis of this chart
   differentiate different behavior.

o  The hierarchy on the left axis describes characteristics of MIB
   objects (as you read in a MIB Module, i.e. not instances). A MIB
   object can be designed to be mechanism-specific,
   mechanism-independent, etc.

   The instance-dependence axis describes how a MIB object is used. A
   MIB object can be used in an instance-specific way or in an
   instance-independent way, depending on how you dictate.

   Also note that the former is a "compile-time" decision and the
   latter is a "run-time" decision.

   The point is that these are additional ways that the horizontal and
   vertical axis describe different characteristics.

o  A single-dimension hierarchy doesn't allow for
   domain-specific/instance-specific objects (for example). In the
   real world, such objects exist so such a model must be wrong.

Regards,
Steve

---

From: Jon Saperia <[email-masked]>
Date: Thu, 28 Jun 2001 05:32:25 -0400

The distinction you make is understood. The objection is that the value
add of the additional dimension to which you speak does not outweigh the
additional complexity.  Once again this taxonomy does not need to become
a class hierarchy - it was not intended to be one.

If you have a specific proposal for a praragraph as I requested the
other week, please make it otherwise we will go with the single
modification we agreed to last week on this list.

/jon

Thanks,
/jon
--