Re: comments on draft-ietf-sming-reqs-02.txt: Reusable vs. Implemented definitions (was concrete vs. abstract)

[Andy Bierman <abierman@cisco.com>]

Frank Strauss wrote:
> 
> Hi!
> 
> >> > 52: We believe that 4.2.3 should be an accepted requirement and be
> >> >     moved to section 4.1. We need to be able to distinguish between
> >> >     reusable definitions and "final" definitions that should not be
> >> >     further refined.
> >> >
> >> [Dave] As I recall, Wes had an issue with abstract vs. concrete and
> >> understanding what it means w/ respect to a MIB. I don't recall him saying
> >> it was a bad idea to differentiate between the two, however. So, unless
> >> someone comes forward against moving this back to an accepted requirement
> >> (going once, going twice...)
> 
> DH> I don't feel that the need for abstract structures has been
> DH> demonstrated, and we have no operational experience of the use of
> DH> abstract structures in either SMI or SPPI.
> 
> Sure, since SMI and SPPI don't allow inheritence.

Exactly. We have lots of experience with cut-and-paste instead ;-)
I am currently editing the DSMON MIB for the RMONMIB WG, and 
this document could be reduced from 125 pages to about 30 pages if the
SMI supported inheritance. I want a template to say (in SMI syntax of course):

 "barControlTable:
  This control table is just like the fooControlTable, except 
  it has one more mandatory read-create parameter, and upon
  activation, the agent doesn't create an associated fooTable - it
  creates an associated barTable instead."

 "barTable:
  This data table is just like the fooTable, except the INDEX
  includes the barNewIndex inserted between the second and
  third INDEX components. The barNewIndex object describes the 
  additional classification required for lexicographical ordering.
  In addition to the fooTable counters (i.e. adapted to the new 
  barTable INDEX classification) the barAcmeProtocolPkts counter
  is maintained by the agent in each barEntry."

Not only does the DSMON MIB require a massive cloning effort, but 
there isn't the slightest machine-parsable clue that any
relationship between a particular RMON-2 and DSMON table exists.

But I don't this is a requirement, just a very-nice-to-have.

Andy

> 
> The reasoning for `abstract' (which is not a good word) definitions is
> to avoid people to some degree from shooting themselves in the foot.
> 
> I think it would be good to have a mechanism that avoids people from
> mapping (the attributes of) a single class to (multiple columnar
> objects in) multiple tables with different OIDs. E.g., if you define a
> Filter and derive a SubFilter, you want every *Filter to appear in a
> *single* SNMP table and you want just the additional attributes of
> the SubFilter to appear in an augmentation table.
> 
> Another reason is that some attribute groups just don't make sense
> to be instantiated. They are just useful for containment in other
> attribute groups. An example is an InetNetworkEndpoint which can
> be contained in a TCP connection table and other groups, but which
> should not be mapped itself to a table.
> 
> DH> No examples are given in this document, and I fear that there
> DH> may be assumptions made about how abstract structures would be
> DH> used that are not clearly identified here.  Before this is made
> DH> a requirement, I think there needs to be serious discussion
> DH> about the possible uses to which they would be put, and how
> DH> that might impact the language and the protocols that would use
> DH> them.
> 
> For the same reason I have severe concerns about inheritence (see
> my example above). In order to restrict the (mis)use of inheritence,
> I could imagine something like a mechanism to diffentiate between
> inheritable attribute groups and "final" attribute groups. That's
> what this `abstract' requirement is about.
> 
> DH> I therefore believe that 4.2.3 should remain a nice-to-have,
> DH> not a requirement.
> 
> Maybe, I agree. ;-)
> 
>  -frank