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

Re: snmpconf BCP re: policy layering

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

	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.

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

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'

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


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
I deferred discussing his points untilnow: He wrote:

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

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?

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


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