Re: Some questions on the base sming document

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

Hi!

Joel> 1) In the text on the "unique" statement, it says several odd things:
Joel> 1a) "If the `unique' statement is not present the class is not meant to
Joel>     be instantiated directly, but just to be contained in other classes
Joel>     or to be the parent class of other refining classes. This, it can be
Joel>     regarded as something similar to an abstract class. "
Joel>   But, if the object can be created if it is contained in another
Joel> class, that is not at all similar to "abstract".  Only the second of
Joel> the two cases (the parent class of other regining classes) is
Joel> "abstract".  The common case of an object contained by another object
Joel> is perfectly reasonable.  In fact, Most object systems would allow for
Joel> shared objects which can only be found from some object which
Joel> references them, rather than having global uniqueness properties.
Joel> (The distinction being that an object which is referenced from more
Joel> than one place is not "contained" in the way some object terminology
Joel> sets use the word.)

Ok, I've simply removed the last sentence.

Joel> 1b) "If present, the attribute list must not contain any attribute more
Joel>     than once and the attributes should be ordered so that the
Joel>     attributes that are most significant in most situation appear first.
Joel> Minor point, the "must not" should be capitalized, as the
Joel> "RECOMMENDED" is throughout the document.  

Ok.

Joel> More significantly, what
Joel> does the second sentence mean?  Are we requiring that the attributes
Joel> be ordered?  If not, why include the "should" since the system will
Joel> not be able to take any advantage of the ordering to help searches
Joel> unless it knows that the ordering is always met.

In many situations the order can be regarded as a hint on a reasonable
order of INDEX elements in the SNMP mapping, for example. It *can*,
thus the word "should". The `system' you mention can be an SNMP
manager, which obviously can rely on the order of instance identifying
sub-identifiers.  The question is, how the SMIng core classes are
mapped to SNMP tables.  For this mapping process (done by a human
being, not automatically) I think it's useful to suggest that the
order of the `unique elements' should be meaningful where appropriate
and not completely irrelevant.

Joel> 2) I know that the EoS folks are discussing having ways of returning
Joel> more information on traps / notifications.  Should we consider having
Joel> a way to represent what information should be included with an "event"?

So far, we thought that the question which objects are passed with a
trap/inform is specific to the mapping to an SNMP notification.

Joel> 2') Should we be representing the distinction between reliable and
Joel> unreliable events, or is that a level of distinction that should only
Joel> be represented in the protocol mapping?

I think this also depends on the protocol mapping.

 -frank