Re: Draft minutes from the May SMIng Interim:

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

Hi!

DD> #35: (Abstract Classes) What does abstract mean from a data point
DD> of view.  What value is there in not instantiating a row? There is
DD> confusion around what value abstract provides. Consensus was to
DD> remove this as a requirement.

>> I feel it's quite obvious that a class like InetNetworkEndpoint is not
>> meant to be mapped to an SNMP table as is but just being used as a
>> contained attribute within other classes. This is what is meant by
>> `abstract' classes. I think this *is* a requirement, although the
>> word `abstract' is probably not a good choice.

DD> [Dave] True, though I believe the issue raised was that it may not
DD> always be easy to know what can and cannot be directly
DD> implemented. You may, for example, instantiate a network end-point
DD> and then simply reference it elsewhere. Which makes me wonder:
DD> Would it not be sufficient to imply abstractness by simply not
DD> specifying a way to name instances of (or index) the class?

That's exactly what is in the currently proposed specs: If the `unique'
statement is missing, the class is "abstract". 

Meanwhile, we stumbled on a situation that makes this less practical:
If we keep supporting inheritance, there could be cases where you want
to specify a parent class from which a number of child classes are
derived, but where all classes use the same attribute of the parent
class as a uniqueness attribute. In this case, you would probably want
to specifiy a `unique' statement in the parent class, although it is
not intended to be mapped to a specific table.

However, we are probably diving to deep into technical questions, where
we lack experience at this point in time.

My point on #35 was just to *not* remove it as a requirement.


DD> #59: (Comments) If we go with a C-like language, then change the
DD> comment, otherwise what's the point. This is not the problem, and
DD> not a requirement.

>> It *is* a problem that many people expect an expression like `-----'
>> to be syntactically correct and let the rest of the line be a
>> comment. I feel it is at least a `should' requirement to get rid of
>> this problem.

DD> [Dave] I think the conversation was that this is all part of human
DD> readability. But given that this is a particularly annoying part of the
DD> current SMI, I don't see why it's not nice to have in any case.

Ok. Making this part of #2/#3 would be fine with me. I would just feel
unhappy, if the requirements document would have a section of denied
requirements that lists this explicitly as a rejected issue.


DD> #61: (Place of Module Information) Remove the module identity
DD> clause? Put the contents into the Module wrapper? This doesn't
DD> seem broken in the current SMI. Issue also for assigning the
DD> root. There is no value in changing this. If anything, it could be
DD> clarified as to how one assigns an oid for this module
DD> identity. Still we will have to do it he old way when mapping to
DD> MIBs and PIBs. Not a requirement.

>> It is not true that MODULE-IDENTITY is used to assign a `root OID' to
>> a module. In fact, there is even no such thing like a `module root
>> OID' in the SMIv2. 

DD> [Dave] Hummm, I recall the claim that MODULE-IDENTITY was used to
DD> assign a root OID from the interim. I will update the
DD> minutes. Since the claim is not true, than the logic for not
DD> making this a requirement is probably flawed as well.

I just wanted to clearify that one of the arguments against dropping
the MODULE-IDENTITY wrapper is not valid. My preference would be to
drop it for simplicity.  However, the issue of assigning an OID for
mapping back to SMIv2 is valid. That's why there is an `oid' statement
in the SNMP mapping specs (Section 4.1 of draft-ietf-sming-snmp-02).


DD> #68: (Module Namespace) What problems is this solving? Name
DD> clashes. Still have to work with old names. Is this a language
DD> issue, ie. BCP? Too many rules is not a good thing. Conclusion:
DD> Remove.

>> I cannot remember that it was the conclusion to remove this
>> requirement (i.e., not to solve the problem of module name clashes).

DD> [Dave] It was to be merged with 6 because it seemed to be a
DD> redundant requirement. It was not being removed. To quote the
DD> minutes: "Consensus that #6 (Modules), and #68 (Module Namespace)
DD> are related, remove first part (naming) as is covered by 5."

Ok. Thanks.


 -frank