Aggregate Attributes

[Fred Baker <fred@cisco.com>]

It was asserted that "aggregate objects" and the concept of "attribute 
groups" and "containment" were related. I went back and read the draft to 
see why I was so dense as to miss that.

It says (comments following):

At 01:33 PM 8/31/2001, fred@cisco.com wrote:
>    Another motivation is to permit a more expressive and complete
>    representation of the modeled information.  Examples of additional
>    expressiveness and completeness that are considered are the ability
>    to formally define table existence relationships, the expression of
>    instance creation/deletion capabilities, and the ability to define
>    attribute groups using inheritance.  These additional features are
>    discussed in subsequent sections.
>
>    Description: SMIng must provide mechanisms to uniquely identify
>       attributes, groups of attributes, and events.  It is necessary to
>       specify how name collisions are handled.
>
>    Motivation: Allows to group related attributes together, such as
>       InetAddressType (discriminator) and InetAddress, InetAddressIPv4,
>       InetAddressIPv6 (union).  The lack of discriminated unions has
>       also lead to relatively complex sparse table work-around in some
>       DISMAN mid-level manager MIBs.
>
>4.1.28 Attribute Groups
>
>    Description: An attribute group is a non-divisible, extensible
>       grouping of attributes that are meaningful together.
>
>    Motivation: Required to map the same grouping of attributes into SNMP
>       and COPS-PR tables.  Allows to do index reordering without having
>       to redefine the attribute group.  Allows to group related
>       attributes together (e.g.  InetAddressType, InetAddress).
>
>       The ability to group attributes provides an indication that the
>       attributes are meaningful together.
>
>4.1.29 Containment
>
>    Description: SMIng must provide support for the creation of new
>       attribute groups from attributes of more basic types and
>       potentially other attribute groups.
>
>    Motivation: Simplifies the reuse of attribute groups such as
>       InetAddressType and InetAddress pairs.
>
>    Notes: Containment has the implicit existence constraint that if an
>       instance of a contained attribute group exists, then the
>       corresponding instance of the containing attribute group must also
>       exist.
>
>    Description: SMIng must provide support for mechanisms to extend
>       attribute groups through single inheritance.
>
>    Motivation: Allows to extend attribute groups, like a generic
>       DiffServ scheduler, with attributes for a specific scheduler,
>
>       Inheritance has the implicit existence constraint that if an
>       instance of a derived attribute group exists, then the
>       corresponding instance of the base attribute group must also
>       exist.
>
>       Inheritance could help to add attributes to an attribute group
>       that are specific to a certain protocol mapping and do not appear
>       in the protocol-neutral attribute group.
>
>4.1.31 Reusable vs. Final Attribute Groups
>
>    Description: SMIng must differentiate between "final" and reusable
>       attribute groups, where the reuse of attribute groups covers
>       inheritance and containment.
>
>    Motivation: This information gives people more information how
>       attribute groups can and should be used.  It hinders them from
>       misusing them.
>
>    Notes: This objective attempts to convey the idea that some attribute
>       groups are not meant to stand on their own and instead only make
>       sense if contained within another attribute group.
>
>    Description: SMIng must allow the specification of uniqueness
>       constraints on attributes.  SMIng must allow the specification of
>       multiple independent uniqueness constraints.
>
>    Motivation: Knowledge of the uniqueness constraints on attributes
>       allows to verify protocol specific mappings (e.g.  INDEX clauses).
>       The knowledge can also be used by code generators to improve
>       generated implementation-specific data structures.
>
>    Description: SMIng must not assign OIDs to reusable definition of
>       attributes, attribute groups, events, etc.  Instead, SNMP and
>       COPS-PR mappings must assign OIDs to the mapped items.
>
>    Motivation: Assignment of OIDs in protocol neutral definitions can
>       complicate reuse.  OIDs of synonymous attributes are not the same
>       in SMI and SPPI definitions.  MIBs and PIBs are already registered
>       in different parts of the OID namespace.
>
>    Motivation: Allows an attribute to contain one of many types of
>       values.  The lack of unions has also lead to relatively complex
>       sparse table work-around in some DISMAN mid-level managers.
>       Despite from discriminated unions (see Section 4.1.19), this kind
>       of union has no accompanied explicit discriminator attribute that
>       selects the union's type of value.
>
>    Description: PIB and MIB row attributes reference a group of entries
>       in another table.  SPPI formalizes this by introducing PIB-TAG and
>       PIB-REFERENCES clauses.  This functionality should be retained in
>       SMIng.
>
>    Description: SMIng should allow the definition of a SEQUENCE OF
>       attributes or attribute groups (Section 4.1.28).
>
>4.3.2 Attribute Value Constraints
>
>    Description: SMIng should provide mechanisms to formally specify
>       constraints between values of multiple attributes.
>
>    Motivation: Constraints on attribute values occur where one or more
>       attributes may affect the value or range of values for another
>       attribute.  One such relationship exists in IPsec, where the type
>       of security algorithm determines the range of possible values for
>       other attributes such as the corresponding key size.
>
>4.3.3 Attribute Transaction Constraints
>
>    Description: SMIng should provide a mechanism to formally express
>       that certain sets of attributes can only be modified in
>       combination.
>
>    Motivation: COPS-PR always does operations on table rows in a single
>       transaction.  There are SMIv2 attribute combinations that need to
>       be modified together (such as InetAddressType, InetAddress).
>
>    Notes: Alternative is to either use Methods (Section 4.2.1) or assume
>       that all attributes in an attribute group (Section 4.1.28) are to
>       be considered atomic.
>
>    Description: Ability to formally depict existence dependency, value
>       dependency, aggregation, containment, and other relationships
>       between attributes or attribute groups.
>
>    Notes: This objective was deemed too general to be useful and instead
>       the individual types of relationship objectives (e.g., pointers,
>       inheritance, containment, etc.)  are evaluated on a case-by-case
>       basis with the specific relationships deemed useful being included
>       as accepted objectives.
>
>    Motivation: If you have an association between attribute groups A and
>       B, the cardinality of A indicates how many instances of A may be
>       associated with a single instance of B.  Our discussions in
>       Minneapolis indicated that we want to convey "how many" instances
>       are associated in order to define the best mapping algorithm -
>       whether a new table, a single pointer, etc.  For example, do we
>       use RowPointer or an integer index into another table? Do we map
>       to a table that holds instances of the association/relationship
>       itself?
>
>    Description: The SMIng documents should give clear guidance on which
>       kind of information (with respect to generality, type/attribute
>       group/extension/..) should be put in which kind of a module.

now, what I mean by an "aggregate attribute" is the construct of that name 
in ASN1 - a value which itself contains named values, but with a 
short-hand, context-sensitive name. It is theoretically possible to change 
any of the subfields individually, but in cases like the requirements draft 
takes note of (the InetAddress, InetAddressPrefixLength, and 
InetAddressType) I'm not certain why one would actually do so.

But the other ones I mentioned - an ARP Entry, an IP Route Entry, and OSPF 
LSA, and so on, I could also imagine an entire SNMP "Entry" in a "Table" 
being an aggregate attribute, and once one can do that, then being able to 
name and change a sub-attribute becomes important. I can imagine some 
saying "but for those we want you to have to go through all the folderol 
that SNMP forces you to go through". I will disagree, but that's  a 
discussion that perhaps becomes a matter of preferences.

What I note in the text above is that "attribute group" and "containment" 
are used without definition. May I suggest that a strong definition be 
written for those concepts, so that when someone reads this requirements 
document they know for sure what is required and what is not?