RE: Draft minutes from the May SMIng Interim:

["Durham, David" <david.durham@intel.com>]

Replies inline:
-Dave

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

[Dave] Yes, I believe this was a nice-to-have from reading the comments.
>  
> 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.
> 
[Dave] I think the conversation was that this is all part of human
readability. But given that this is a particularly annoying part of the
current SMI, I don't see why it's not nice to have in any case.
> 
> 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. 
> 
[Dave] Hummm, I recall the claim that MODULE-IDENTITY was used to assign a
root OID from the interim. I will update the minutes. Since the claim is not
true, than the logic for not making this a requirement is probably flawed as
well. 
> 
> 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.
> 
[Dave] Okay.
> 
> 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).
> 
[Dave] It was to be merged with 6 because it seemed to be a redundant
requirement. It was not being removed. To quote the minutes: "Consensus that
#6 (Modules), and #68 (Module Namespace) are related, remove first part
(naming) as is covered by 5."
> 
>  -frank
>