RE: Process for SMIng Syntax Proposal Submissions:

[Andy Bierman <abierman@cisco.com>]

At 02:16 PM 10/31/2001 -0500, Glenn Waters wrote:

> You say that you are proposing a
> revolution. You also said that you think that this can be done with the
> current set of proto-ops. 

I think the current proto-ops will work for the accessible objects.
High level proto-ops (e.g. RowStatus) need to be re-evaluated.
I didn't get this right in my DSMON example.  Since 
containment
is preserved (instead of unfolded into tables), there's no need
for lots of RowStatus objects at lower levels of containment.
There can be 1 RowStatus (now a bad name) for the entire data
structure,
if that's what the designer wants. 

The concepts (and mechanisms) of AUGMENTS and EXTENDS have to be 
adapted for a data structure POV, not a table POV, but that's not really
a
proto-ops issue.

> My question is do you think that
> we SHOULD use the current set of proto-ops or that we COULD use them. If
> you say COULD how painful would it be for all involved - i.e.: agent
> writers and app developers.

The current proto-ops are biased towards tables, as is the current EOS
work.
The GetNext and GetBulk PDUs are optimized for a naming structure
with
all the instance OIDCs on the end of an OID. 

The use of lexinext as a Poor Man's Fragmentation mechanism is a serious
weakness
of SNMP.  I want PDUs that allow high level objects (or sub-objects)
to be set or retrieved, 
but the use of UDP prevents this.  We need the management protocol
to adapt to
the management data, not the other way around.


> Do you think that new proto-ops
> would be useful? 


Yes, but I think a new transport protocol mapping would be needed
first.


> /gww 


Andy



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