What is the proper behavior for a GET when MFD_SKIP is returned?

I am writing an agent using 5.2.1 and mib2c/mfd. If my agent receives a GET request, but the column has not been implemented yet, I return MFD_SKIP. If I use snmpget to kick off a GET request, the *_interface.c code returns ASN_PRIV_RETRY and no error. This ends up causing retries, until snmpge

"Holes" in oid sequence.

Is it "legal" to define a MIB with holes in the oid numbering to allow for features that are unknown today to be added at a later date??? I.e., a table with oids: .1.3.6.1.23.1.1 .1.3.6.1.23.1.2 .1.3.6.1.23.1.3 <- 4,5,6,7,8,9 skipped. .1.3.6.1.23.1.10 .

Re: "Holes" in oid sequence.

Dave Shield wrote: The cardinal rule of MIB design is that you should never have two definitions with different behaviour sharing the same OID. We're continually adding new features to our product, and that's in conflict with the cardinal rule above. The process that I'm considering is t

What should an agent return if the object doesn't exist?

Right now our MFD based agent returns MFD_SKIP if an object doesn't exist, and that's gets translated by net-snmp into a value being returned who's type is, SNMP_NOSUCHINSTANCE (which is really ASN__CONTEXT | ASN_PRIMITIVE | 0x1). This seems correct according to the RFC (A snippet follows).