RE: Process for SMIng Syntax Proposal Submissions:

[Andy Bierman <abierman@cisco.com>]

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.