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

Re: snmpconf BCP re: policy layering



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
> 
> 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
> 
> 
> "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
> 

Thanks,
/jon
--

Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/