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

Re: snmpconf BCP re: policy layering

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

Jon Saperia wrote:
> 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.
> > 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
> 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.

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.


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

> > > 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
> I think we have this covered pretty well and there is not issue here.
> > >   instance-specific/mechanism-independent:
> > >       ifInErrors.7
> 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.

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.

> Notice that what we are discussing here are not more or different levels
> of the hierarchy, just different relationships.
> > >   instance-independent/mechanism-specific:
> > >       dot3StatsAlignmentErrors on all trunk ports
> Is a trunk a mechanism?

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

> > >   instance-independent/mechanism-independent:
> > >       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.

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