Probably too late for this, but...

[Michael Kirkham <mikek@muonics.com>]

Sorry for being way late on this, but I was out of touch for a few months
and wasn't aware of the SMIng project going on.  There's been a little bit
of discussion on the SNMPv3 WG mailing list the past week I'd hoped to put
forth if/when there was an SMIng project.  I guess I missed it, but here
it is anyway.  Please forgive me if my notation is off or this reflects an
unfamiliarity with new rules/etc. in SMIng, as I'm just coming up to speed
on the new specs.

In the goal of providing syntax for optimized parseability, there are
certain things in the area of "must nots" that currently (and I gather in
my brief scanning, that includes SMIng) can only be done via human
readable (non-parseable) text.  Primarily this is in the area of allowed
values for gets/sets to objects such as with RowStatus (e.g.
'createAndWait' and 'createAndGo' can be written but never read).

For the 'typedef' statement, I would suggest the following changes:

   typedefStatement        = typedefKeyword sep ucIdentifier optsep
                                 "{" stmtsep
                                 typedefTypeStatement stmtsep
                                 typedefReadTypeStatement stmtsep
                                 typedefWriteTypeStatement stmtsep
                                 *1(defaultStatement stmtsep)
                                 *1(formatStatement stmtsep)
                                 *1(unitsStatement stmtsep)
                                 *1(statusStatement stmtsep)
                                 descriptionStatement stmtsep
                                 *1(referenceStatement stmtsep)
                             "}" optsep ";"

Where 'typedefReadTypeStatement' maps to 'read-type' and
'typedefWriteTypeStatement' maps to 'write-type'.  This would allow
restrictions on get/set values such as those of RowStatus to be parseable:


       typedef RowStatus {
           type        Enumeration (active(1), notInService(2),
                           notReady(3), createAndGo(4),
                           createAndWait(5), destroy(6));
           read-type   Enumeration (active(1), notInService(2),
                           notReady(3));
           write-type  Enumeration (active(1), notInService(2),
                           createAndGo(4),
                           createAndWait(5), destroy(6));
           
           ...
       }

As another example, it would also be useful, for example, for the USM
KeyChange textual convention, which says:

         "The value of an object with this syntax, whenever it is
          retrieved by the management protocol, is always the zero
          length string."

You would be able to represent this as...

       typedef KeyChange {
          type         OctetString;
          read-type    OctetString (0);
          ...
       }

I haven't come up to speed enough on SMIng to see how managed objects are
defined without typedefs (if they can be), but I would say that the same
additions apply there.

In the 'compliance' statement, it would be useful to be able to specify
similar restrictions based on compliance levels in MIBs where a compliance
level represents a unique subclass of device (though a device could claim
to be part of both subclasses), such as a cable modem or cable modem
termination system.  One such example (though perhaps not a good one, as
it may not be the specific intent with this particular object) is the
docsDevRole object, which is defined as:

    docsDevRole OBJECT-TYPE
        SYNTAX INTEGER {
            cm(1),
            cmtsActive(2),
            cmtsBackup(3)
        }
    ...

...where cable modem carries the value cm(1) while a cable modem
termination system may carry either cmtsActive(2) or cmtsBackup(3).  It
would be nice to be able to specify this in the conformance statements,
where you would have a conformance for a cable modem and a conformance for
a cable modem termination system, rather than (solely) in the description
for docsDevRole.

Similar additions would be useful, though perhaps less so, for access
levels -- at least for completeness.

These would be additions to the notation, and not meant to remove the
capability to specify "minimum" levels of conformance.  Rather, they'd be
geared largely toward subclassing where discreet subclassing is desired.

Finally, also in the realm of compliance statements, I believe it would be
useful to expand upon the mandatory/optional group semantics to allow
groups to require other groups.  I mentioned this around August '98 as a
possible addition for SMIng.  In the old notation I used then:

    GROUP        myMainGroup
    STATUS       optional
    DESCRIPTION
       "Some optional group that requires other groups if implemented"
    REQUIRES     { subGroup1, subGroup2, someOtherObject }

I don't have particular opinions about how it should be represented in the
new syntax, but I do strongly believe that it would be useful to have a
way of saying, in a parseable notation, that a group is optional but if
you implement it then you must implement certain other groups as well.

Again my appologies for being late in the game here and for any errors
I've made in my notation or rehashing topics from previous SMIng
discussions that I missed.