[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf Policy MIB: Pre-processor

Hi Pablo--by the way, this is *great* input you're contributing here. :)

At 11:45 AM 11/7/2000 -0500, Pablo Halpern wrote:

>The document lists a number of #defines for important constants. This 
>implies a C preprocessor. In the interest of keeping the language small, I 
>suggest that we do away with the C preprocessor in the agent code. 
>Instead, we would encourage implementors of management applications to 
>provide a C preprocessor through which code is processed before being sent 
>to the Policy agent. We are already recommending that management 
>applications perform substitution OIDs for MIB variable names, so I see 
>this suggestion as entirely consistent.

At the interim meeting, we struggled with this a fair amount.  The result 
was a real Hobson's choice deferring to a deployment reality as it stands 
now--and one which some of us aren't completely thrilled with.

In the first place, the "#define's" that the document references were 
placeholders for a greater "global constant" gestalt that the policy MIB 
framework requires.  This is to say, all of the examples in the policy MIB 
document were for the benefit of the implementation, and did *not*, as of 
that  writing, imply that such a facility was available for the policy author.

So, one might ask, why *not* make such a facility available to the policy 
author.  Well, at least, I asked. :)

For starters, the notion of a formalized "#define" preprocessor construct 
was rejected for all the reasons you mentioned (in addition to the fact 
that we don't want to go promoting the more byzantine aspects of the 
typical C language implementation, such as preprocessor substitution in 

So, the option is some sort of "const" mechanism.  However, since the 
policy MIB should be implementable in an agent with the minimum amount of 
additional resources required for this realization, we can't assume the 
ability for *any* agent-side symbolic substitution.

Now, it is certainly something that a *given* management station which is 
tailored to the SNMPConf policy authoring function could itself implement, 
doing substitution of real OID's and constant values prior to writing them 
to the Policy MIB agent (that was my read on the outcome, anyway).

This has an unfortunate side effect--on reading the policy back in, there's 
no way to accurately "substitute back" the symbolic reference.  So, while a 
given implementation (and I think the idea is to not have the I-D reference 
this facility at all, or certainly to flag it as utterly optional) may be 
able to do a substitution from a human-readable const reference for OID's 
and scalars (timeout values, addr prefixes, etc.), they will be read *back* 
from the Policy MIB agent as hardcoded values.

It's not pretty, but we haven't yet come up with a clean way to resolve 
this to everybody's satisfaction.

The revision of the Policy MIB document which Steve is working on based on 
Knoxville input should address this point.

Somebody correct me if I'm misstating how we ended up on this issue.


Wayne F. Tackabury		Internet: wayne@goldwiretech.com
Gold Wire Technology		Phone: (781) 647-2211, x213
411 Waverley Oaks Rd., Ste. 331
Waltham, MA  02452          Cell: (617) 699-6156