RE: Process for SMIng Syntax Proposal Submissions:

["Durham, David" <david.durham@intel.com>]

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?

-Dave
-----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.