Re: Process for SMIng Syntax Proposal Submissions:

[Andy Bierman <abierman@cisco.com>]

At 06:00 PM 10/29/2001 -0800, David T. Perkins wrote:
>HI,
>
>Looks like much work that Andy spent on the example. Thanks!
>
>One simple question? Will GETNEXT/GETBULK still work when given
>arbitrary OID values? Which is a specific part of the question
>"Will an agent be able to figure out the different components
>of the OID for a variable in all definitions for all operations?"


Yes to all 3 questions.
I don't believe the SNMP ProtoOps are affected by my proposal.
The naming scheme is different, so the objects don't lexi-sort
exactly as they do in SMIv2, but they do lexi-sort.

GetBulk may be optimized for SMIv2. I don't know if the fragmented
instance makes getBulk more or less efficient.

Conceptually, an SMIv2 instance ID looks like:
     <base-OIDs-for-all-layers>.<instance-OIDs-for-all-layers>
even though there is only one layer.

A hierarchical naming scheme (like I am proposing) is broken up by layers,
which allows different levels of granularity (although SNMP as it exists
today can only convey object instances -- leaf nodes):
<layer1-base>.<layer1-instance>.<layer2-base>.<layer2-instance>....

Another design break from SMIv2: accessible instances can exist at
any level.

There is the issue of infinite recursion when a compiler resolves complex
data types (same for a C compiler).  Well-formed SMIng definitions
do not loop. Forward pointer declarations are allowed in C, but I don't think
we need all the complex pointer features of C in the SMI. (Pointers cause
some complex issues.)

>Regards,
>/david t. perkins


Andy