Subject: RE: Andy's review of draft-ietf-snmpconf-pm-09.txt

From: "Harrington, David" <[email-masked]>
Date: Mon, 28 Jan 2002 08:15:08 -0500

Comments inline

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]]
> 
> 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.

dbh