> -----Original Message-----
> From: Andy Bierman [mailto:email@example.com]
> It's not really under-specified, but rather just not well organized.
> The big areas for improvement:
> - explain the whole before diving into the details of the parts
> - collect related information into one place
> - remove all forward references to concepts, MIB objects, and terms
> - make examples consistent and correct, and use lots of them
> - attempt the clarify the runtime behavior and document one
> suggested implementation strategy of the runtime environment
These were also the cause of many of my comments. I've been involved in the snmpconf effort, and had difficulty wading through all the forward references and the little rules about implementations throughout the document.
> >2) Andy comments repeatedly about strings appearing in
> places where they "are not allowed". It appears that Andy
> missed (and therefore we need to emphasis better) the fact
> that these strings are supposed to be processed on the front
> end. The fact that we are not mandating a front end, but are
> describing all our examples as if there is a smart front end
> does produce a tension (rather like the on in (1) above) that
> should be addressed. I actually muchly prefer the use of the
> text strings, as if the examples used explicit numeric OIDs I
> would have no idea what the examples were doing.
> IMO, the WG is making a flawed assumption about scripting, by
> requiring a front end to translate some parts of the source code
> before loading the pmPolicyCodeTable. Humans should be able to
> generate 100% of the source code without additional tools.
> (That's why I put an OID Alias table in the SEE MIB.)
> The examples should show the real ASCII-dotted OID and the string
> version in a comment. It is very confusing to see all those
> verbose disclaimers about how the code really doesn't look like
> this -- it's human nature to assume the authors would only include
> valid examples of the programming language, and base their own
> code on those examples.
I have a concern that we are giving examples that do not reflect what the language actually supports.
I feel that the reason this is being done is that nobody would be able to understand the scripts if the supported formats were used everywhere. But we expect operators to write interoperable scripts without the benefit of writing it with text names. If people involved in SNMP as much as we are cannot make sense of a script "snippet" if it is written with OIDs, imaging the state we are forcing on an operator who needs to configure policies for a complete router using complex scripts that contain only the raw OIDs and raw parameters.
While I agree with Andy that it is undesirable to force users to use an application to write meaningful scripts, I suspect that many in this WG assume there will be a pre-processor involved. We don't make that easy for users; do the expected preprocessors contain hard-coded aliases for known OID equivalents?.
If we expect operators to use a preprocessor why don't we provide them with preprocessor commands like #define, #include, etc. Armed with this, users could optionally provide header files of defines to standardize the naming of the OIDs and easily reuse the definitions across multiple scripts, and we can standardize the community's expectations about how text in a script gets changed to the raw OIDs. If we also added #if, #else, #then directives, scripts could also hide some of the variations between target devices' objects in their header files, improving the interoperability and reusability of their scripts.
> It would be extremely challenging for a non SNMPCONF WG member to
> fully implement the PM MIB just by reading this document, let alone
> getting two of them to create inter-operating implementations.
I think it will be difficult for SNMPCONF WG members to do so, basing it solely on reading the document as currently written.