Hi!
Mark> [...] Anyway, I agree that all the information should be in some Mark> kind of formal construct, but:
Mark> 1. The SMI constructs do not answer all needs. There is no Mark> good/easy way to explain a dependency between two or more Mark> objects.
I agree. But I don't see how comments could serve this need any better than DESCRIPTION clauses.
Mark> 2. Descriptions which contain all the information might get Mark> very big, especially where enums are concerned, which makes Mark> harder their reading and understanding. When I'm (as a sysadmin) Mark> need to know what does the number 4 means for StorageType Mark> (RFC2579) it is much faster to learn it from the comment then Mark> from the description. What is worse is that there is no Mark> automatic way to associate an enum with its explenation Mark> contained at the description.
The length of a text does not make it more or less appropriate for being placed in a DESCRIPTION or comment. I don't think that
SYNTAX INTEGER { [...] nsip(27), -- XNS over IP slip(28), -- generic SLIP ultra(29), -- ULTRA technologies ds3(30), -- DS3-MIB [...]
or more or less difficult to read than e.g.
DESCRIPTION " [...] nsip 27 XNS over IP slip 28 generic SLIP ultra 29 ULTRA technologies ds3 30 DS3-MIB [...]
The problem is, that there is no formal structure in both cases and there is some redundancy (which should only worry the author and not the reader or the MIB). The advantage of the second approach is that you can access this information also from an arbitrary MIB browser.
Mark> 3. In practice comments apear in many MIBs, even some of the Mark> standard ones has some non trivial comments. The fact that Mark> current MIB browsers do not know how to handle comments, does Mark> not mean that the end user will not benefit from reading them.
Comments are meant for readers and authors working at the same level as the original MIB author. They are not meant for any higher level processing or application. That's true for all computer languages that come to my mind (except some uggly compiler directives).
I don't see a need to support wrong usage of comments (especially because a useful interpretation of comments would be quite difficult to implement and *cannot* be reliable). And AFAIK standard MIB revision processes are much better these days, so that in recent MIBs you won't find `useful' information in comments.
Mark> The way I see libsmi, it is a generic tool to compile MIB files Mark> to other formats/langauges, therefor I don't see the point of Mark> limiting the generated format to "formats which do not contain Mark> comment information".
I agree. But I think, that's not the point.
-frank