Re: Requirements Feedback

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Jason, Jamie writes:

Jason> Some questions regarding some of the SMIng requirements.

Jason> 1.  Can someone please elaborate on the differences between #14
Jason> (Instance Pointers) and #15 (Row Pointers).  Can they be
Jason> thought of in this way?  Instance pointers are typed pointers,
Jason> whereas row pointers are void pointers.  With the distinction
Jason> being that an instance pointer may only reference a row in one
Jason> type of table, while a row pointer may reference a row in any
Jason> kind of table?

I think the terms are used as defined in RFC 2579 (InstancePointer and
RowPointer). The RowPointer always points to an instance of a row
while the InstancePointer can also point to a particular cell in a
table. Note that this has nothing to do with a typed pointer (a
concept which does not really exist in SMIv2). SPPI however has ways
to type pointers - that is to restrict them so that they can not point
to everything.

(Using a class-based terminology, the difference is whether we are
 done with supporting pointers to class instances or whether we also
 need pointers to concrete attributes of class instances.)

Jason> 2.  In example for #20 (Events), the event linkDown has (or
Jason> seems to have) two attributes - one of type status and a
Jason> description.  Is it possible to have more attributes for an
Jason> event?

Not at this point in time. Do you think more is needed? What and why?

Jason> 3.  #28 (Categories) - is this akin to C++ namespaces
Jason> (apologies to those who are not familiar with them) in that
Jason> they allow for scoping in order to reduce/prevent name
Jason> collisions?  Or, is this the purpose of #68 (Module Namespace)?
Jason> If #68 serves this purpose, I would like some more
Jason> clarification on #28 so that I can get them straight in my
Jason> mind.

This #28 is not about C++ namespacese. Categories are a way to
categorize definitions - e.g. all the definitions relevant for a
diffserv manager or all the definitions relevant for the security
manager. COPS/PR and SPPI have this concept. The SNMP world sometimes
uses contexts to achieve something similar. I once had a long debate
with Keith about the difference between contexts and subject
categories and I am still confused about it. ;-)

Jason> 5.  Would it be possible to name #33 (Classes) to something
Jason> like "Attribute Groups"?

Fine with me.

Jason> 6.  #39 (Arrays) - is this as Andrea thought (a multi-valued
Jason> attribute), or is it a set of multiple attributes?  I can see
Jason> use for having a set of multiple attributes (which is what I
Jason> had thought it was).

My understanding is that this refers to a multi-valued attribute.

Jason> 7.  Am I right in assuming that #64 (Make Status Information
Jason> Optional) refers to status information that is most useful to a
Jason> human?  For example, if something is deprecated, a compiler
Jason> could inform the user that they are depending on/deriving
Jason> from/referenceing something that has been deprecated in a
Jason> manner similar to how the Java compiler does.  If we go down
Jason> the path of keeping the status information for the purpose of
Jason> providing meaningful information from compilers, do we go down
Jason> the road of also supplying additional information.  For
Jason> example, in the case of a deprecated class that is inherited
Jason> from, should there also be information that states the name of
Jason> the new class that should be inherited from instead?

Issue #64 only deals with the proposal to make the status statement in
the language optional in order to make definitions more compact and
easier to read for humans. Issue #64 does not propose to change the
semantics of the status values as they are used in the SMIv2 or the
SPPI.

What compilers to with the status values is implementation specific.
Sure, a good compiler should warn if current definitions depend on
deprecated or obsolete definitions. I personally would leave it to the
MIB authors who deprecates definitions to explain the situation in the
description clause. I personally prefer to not add language complexity
in this case as the benefit does not seem clear/convincing to me.

/js