RE: Process for SMIng Syntax Proposal Submissions:

[Andy Bierman <abierman@cisco.com>]

At 10:18 AM 10/31/2001 -0800, Durham, David wrote:
>This is an interesting proposal... Certainly the most complete example I've
>yet seen making use of a relative OID namespace hierarchy. I believe Wes was
>also advocating something along these lines a while back. I remember Wes
>having had some second thoughts too though, so I hope he takes a look at
>what you are suggesting (Wes?).
>
>My question is, do you view this as a separate proposal, or as a set of
>suggested modifications and enhancements to the current NMRG proposal?


I'm not sure. (I sent an email to the SMIng authors but I haven't heard 
back yet).
I am currently working on completing the syntax definition and adding some
simple examples. I already made some changes:
      - moved instance sub-OIDs before object sub-OIDs, to match the
        naming in C (e.g.,  foo, foo[1], foo[1].bar -- before foo[1] could not
        be represented.)
     -  settled on 4 basic type constructs
            - SCALAR  (any base type)
            - ARRAY
            - UNION
            - STRUCT
     - extended the SYNTAX clause to provided typed OID pointers, e.g.:
             SYNTAX CONST POINTER InetAddress      (read-only pointer)
        or  SYNTAX POINTER InetAddress                  (read-write pointer)

I'm proposing revolution, not evolution.
The SMIv2 data model based on tables is fatally flawed.
Tables within tables is the wrong way to look at it.
We need a data definition language that let's us define data structures
similar the ones we use in real life, in our code.


>-Dave


Andy


>-----Original Message-----
>From: Andy Bierman [mailto:abierman@cisco.com]
>Sent: Tuesday, October 30, 2001 10:04 AM
>To: Glenn Waters
>Cc: 'sming@ops.ietf.org'
>Subject: RE: Process for SMIng Syntax Proposal Submissions:
>
>
>At 11:59 AM 10/30/2001 -0500, Glenn Waters wrote:
>
>
>This is cool!!
>
>
>
>thanks
>
>
>
>I fully agree with your comment on the separation of OID naming from the
>data definitions. It should NOT BE DONE.
>
>I agree. I have to write these documents with emacs as my only tool-set :-)
>
>
>
>I think I understand what you have done (although I'm not up on the
>DSMON-MIB so I may have misinterpreted some things).
>
>The main points:
>    - SMIv2 version spreads a complex data structure across multiple tables,
>      which share a major index component value.
>      Forget tables -- wrong model. Think object hierarchy instead.
>    - Accessible objects (what I called SCALAR) can exist at the same level
>      as complex objects, like ARRAY, CLASS, or UNION.
>    - Hierarchical naming is needed to allow complex data types to co-exist
>      with scalars at a given scoping level. Just like C, you need to add
>more
>      identifier components to the right to reference base-type objects at
>      deeper levels.  SMIv2 is table-oriented, and bunching all the table
>indices
>        at the end may help deal with rectangular tables, but it doesn't work
>well at all
>        for complex data structures.
>
>
>
>You say that "MODULE-COMPLIANCE TBD" -- I would like to remove
>MODULE-COMPLIANCE from the SMI. It provides little to no value and it is
>difficult to write/maintain.
>
>
>
>Number 1 problem area for cisco mib-police (MIB review board):
>   - creating or updating a MODULE-COMPLIANCE or OBJECT-GROUP maco
>Authors almost always get this wrong. I don't want to remove it though.
>We could not agree on which objects to include in a MIB without
>the flexibility of the MODULE-COMPLIANCE macro.  (It should really
>be called the MODULE-NON-COMPLIANCE macro, since it's used
>to describe all the ways not to conform to the MIB definitions as specified
>in the OBJECT-TYPE macros. :-)
>
>
>/gww
>
>
>Andy
>
>
>
>
> > -----Original Message-----
> > From: Andy Bierman [mailto:abierman@cisco.com]
> > Sent: Monday, October 29, 2001 19:57
> > To: Durham, David
> > Cc: 'sming@ops.ietf.org'
> > Subject: Re: Process for SMIng Syntax Proposal Submissions:
> >
> > At 11:15 AM 10/9/2001 -0700, Durham, David wrote:
> >
> > I am attaching a rough proposal for a SMIng syntax, by way
> > of an example.  I converted the Aggregation Control objects
> > from the DSMON-MIB module to a proposed SMIng format.
> > The SMIv2 version is in draft-ietf-rmonmib-dsmon-mib-07.txt.
> > This new syntax is a cross between SMIv2 and the current SMIng proposal.
> >
> > I have not written up a formal grammar or an item by item
> > objectives assessment. I just wanted to get a non-trivial example
> > out there to encourage discussion of constructs like arrays,
> > unions, pointers, instance naming for an arbitrary number and type
> > of containment levels. (I will do this if there's interest on the mailing
> > list.)
> >
> > I am not trying to separate OID naming from the data definitions,
> > as done with the current SMIng proposal.  I believe this is a horrible
> > thing to do. There should only be one naming scheme for a
> > data definition language.
> >
> > Andy
> >
> >
> >
> > >As recorded in the SMIng meeting minutes from the 51st IETF and presented
>
> > on
> > >the mailing list, with the completion of the objectives I-D the working
> > >group will now address proposals for the next generation SMI. Submissions
>
> > >should ideally be based on grammars that already exist.  These proposals
> > >will be used to drive the cost vs. benefits analysis of the SMIng
> > Objectives
> > >and will be discussed on the mailing list as well as at the 52nd IETF.
> > >
> > >The proposal process acknowledges the existence of the NMRG proposal for
> > >SMIng. The purpose now is to determine if anyone:
> > >     a. Believes there is a suitable existing grammar alternative for
> > SMIng
> > >the WG should consider.
> > >     b. Is willing to write an I-D describing the use of this grammar to
> > >improve the state-of-the-art of the SMI, specifically by addressing the
> > WG
> > >objectives for the SMIng language.
> > >That is, it is not acceptable to dismiss our existing contributions
> > without
> > >formally describing an alternative in the form of an equivalent
> > >internet-draft so that a full and open cost vs. benefits analysis can be
> > >pursued by the WG.
> > >
> > >Contents of the syntax proposal I-Ds shall:
> > >     1. Describe the selected grammar and/or provide references to freely
>
> > >available documents detailing the grammar
> > >     2. Describe the grammar's use as a syntax for naming and describing
> > data
> > >carried by SNMP
> > >     3. State compliance with the accepted SMIng objectives (section 4.1
> > of
> > >draft-ietf-sming-reqs-06.txt) item by item including a syntax example
> > >showing applicability where compliance is claimed
> > >
> > >Proposals must be submitted as Internet Drafts by November 14th, in time
> > for
> > >the ID-00 cutoff date, for discussion at the 52nd IETF.