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

Re: snmpconf-pm-04 notes continued


This comments on just a couple of items in the thread with Steve and

Wes wrote:
> >     I'd actually suggest a note be put into the -bcp document as well
> >     describing that comments should never be used to describe
> >     functionality of objects, but rather to mark things to remember, etc.
Wes, lets start a separate thread on this. I am not sure what you mean
here. Please propose some text. One thing is that I have always felt
that the DESCRIPTION should include information about the side effects
of the behavior of the object on the network. This is not what it was
originally planned for, but people have come (as you point out) to rely
on the DESCRIPTION clause for many different things.

> The problem with this is that often it inhibits readability for those
> reading the document the regular way. At the beginning of a non-trivial
> table I like to describe why it is there and a high-level overview of
> how it works.
> What I've done is fixed up all the comments in MIB, ensuring that every
> piece of "specification" that was in a comment was also in the MIB
> objects and in cases where there was text that wasn't appropriate for a
> high-level intro, I delete the text. I think you'll be happy with the
> results although I didn't do the notification table yet pending my
> getting my act together on your comment #22.

I think what Steve did here is the best solution. The only problem is
that it tends to make the document bigger, but that is a good trade-off
if we get understandability.

> > 24) the capMatch function definition is not clear as to what the OID
> >     should be.  After reading everything, I'm guessing that it should
> >     be an oid corresponding to a pmCapabilitiesType definition, but I
> >     could easily accidentally read it as possibly a
> >     pmCapabilitiesSubType OID or even a row pointer into the
> >     pmCapabilitiesTable itself.
> > 
> >     (while I'm at it, the capabilities table seems almost redundant
> >     with respect to the sysORTable.  There is a lot of overlap and it
> >     took me a while to figure out why both are needed: the table
> >     defined here references mib accessible changes, while the
> >     sysORTable contains only a pointer to a mib object.  I'd be
> >     tempted to write a sysORTable agent-capabilities mib table instead)

Wes, I agree, capMatch pointing to the OID as you suggest in the
capabilities table gives control over the specific capability of
interest. See below for some additional comments I have in this area.

With regard to the sysORTable, I suppose it could be re-written at some
time to perform the functions described by the Capabilities table, but
as you see they are very different. Not only does the Capabilities
reference MIB accessible changes, it makes it possible for a vendor to
express limitations in concrete terms of their implementation. We had a
discussion on  last June/July I sent a summary at that time of a
exchange that Andrew Smith and I had on this topic. In the future, we
could discuss making a table such as the one you propose, but for now,
this seems like the most direct approach to solving the problem in
anything like a reasonable time frame.

> > ***
> > 56) pmCapabilitiesTable should be indexed by the type and/or subtype
> >     for faster traversal when you're looking for a particular
> >     capability.  (The type object really needs a better description,
> >     since I have no idea what its value should indicate other than it
> >     has been "assigned by IANA".)

First with regard to the index. I think you are correct. We should
modify the index to be:

           INDEX       { pmCapabilitiesIndex, pmCapabilitiesType }

See my discussion below in my page 76 comments as to why I think we do
not need the pmCapabilitiesSubType.

Recently I wrote some clarifying text that should go into the front
matter of the document that explains capMatch and Capabilities table

Elements are collections of OIDs and are represented in the Element Type
Registration Table. Capabilities represent one or more OIDs that are
Registered in the Capabilities table. An element may have 0, 1, or more
capabilities.  A SONET interface card may exist in a number of different
vendor's routers, but use different mechanisms and implementation
details to control how that card delivers differentiated services or
provides MPLS functions. This is an important distinction between the
element and capability objects. 

The IETF makes specifications for external behaviors. Internal
implementation details as to how to deliver the specific external
behaviors are left for vendor innovation. For this reason, there
will often be wide vendor differences in how these internal mechanisms
must be configured. These important differences can not be completely
hidden and at some point must be exposed so that correct parameters for
them can be determined and distributed. These differences, are exposed
by the Capability Table. Once these parameters have been 'discovered' by
a management application, it can use them to determine which policies to
send to a network system. The pmPolicyFilter object uses the capMatch
function to check the pmCapabilitiesType(s) associated with an element
to determine if a policy should be applied to that element..

Below are some additional comments that relate to the capability table.

Page 75:

         "The description of a capability or limitation of a
         capability of the system. An entry will exist for each
         domain and mechanism specific ability the system has. In
         the case of a domain specific capability with no mechanism
         specific parameters, the pmCapabilitiesSubType and all other
         columns may be null. ......."

it should read, domain, mechanism and implementation specific

We should also give some specific examples. Here is one: is the base OID of the OSPF MIB Module. This indicates that
the routing subsystem of the managed device supports all features
defined in RFC 1850. 

Wes, here is where I would propose we get rid of sub-type. The
DESCRIPTION of the pmCapabilitiesEntry reads:

         "The description of a capability or limitation of a
         capability of the system. An entry will exist for each
         domain and mechanism specific ability the system has. In
         the case of a domain specific capability with no mechanism
         specific parameters, the pmCapabilitiesSubType and all other
         columns may be null. Entries will exist that contain
         values for the pmCapabilitiesRestrictOID,
         pmCapabilitiesRestrictType, pmCapabilitiesRestrictValue
         and pmCapabilitiesRestrictString objects only when
         an implementation is reporting a mechanism specific
         restriction. Multiple entries are possible when more
         than one restriction for a type or subtype are needed."

With this wording as is, we can specify sub-trees of a MIB Module and
exclude them through the other objects in this table. For that reason, I
think we can remove the pmCapabilitiesSubType object. See my IANA
discussion below

Page 76:

         "The type of the capability represented by this entry.
         The IANA will publish the list of identifiers that are valid
         values for this object."

Reword as:

         "The type of the capability represented by this entry.  IANA
         publishes a list of identifiers that are valid values for this
         object. That is, they are the base OIDs of the standard MIB
         Modules in this list are MIB Modules that can represent
         capabilities with regard to operations and configuration.

Page 76 pmCapabilitiesSubType:

I think we no longer need this object.

Comment on the Capabilities Table. In the same way the the Element Type
can be set by a manager, we should probably also allow this table to be
read-create. Some OIDs can/will be automatically set up, others will
require manager intervention.



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