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

Re: snmpconf BCP re: policy layering



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
> 
> > 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
> coincidence.
> 
> > > > 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
> examples.
> 
> 
> Regards,
> Steve
> 

Thanks,
/jon
--

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