Re: Draft minutes from the May SMIng Interim:

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

Hi!

Some late comments on the minutes...


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> #55: (Core Language Keywords vs. Defined Identifiers) Don't
DD> include bits, but include counter32... don't import any language
DD> key words, base types, etc. Nothing that's part of the
DD> language. So this should be changed to say not to import
DD> stuff. Intention is what is in the language that doesn't have to
DD> be imported. Conclusion: Not a Requirement.

I feel (after the proposed rewording) this is at least a `should'
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> #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> #65: (Units and Default Values of Defined Types) Yes, should be
DD> in.

...and `formats' of attributes/object-types, if we stick with
formats/display-hints.


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).


 -frank