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

Re: snmpconf BCP re: policy layering


  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.


"Wayne F. Tackabury" wrote:
> At 05:51 PM 6/21/2001 -0700, Steve Waldbusser wrote:
> >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.
> 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.
> >A side note: Is this intended as a learning tool? An architecture for
> >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