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

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

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.

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