[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: draft-ietf-eos-snmp-rowops-00.txt



Title: RE: draft-ietf-eos-snmp-rowops-00.txt

I think that one reason you would NOT want to use tablePart instead of tableEntry is that would preclude retrieving a scalar object. The currently proposed encoding method would allow the retrieval of a scalar.

Retrieval of a scalar in a "row" operation is important for something such as sysUpTime which is often retrieved along with a row.

/gww

> -----Original Message-----
> From: Lauren Heintz [mailto:lheintz@cisco.com]
> Sent: Tuesday, May 1, 2001 19:57
> To: Robert Story
> Cc: internet-drafts@ietf.org; EOS WG (E-mail)
> Subject: Re: draft-ietf-eos-snmp-rowops-00.txt
>
> Robert Story wrote:
> >
> > >3.2.1.  The rowIdentifier
> > >...
> > >   A more meaningful representation for rowIdentifier is now possible:
> > >
> > >      rowIdentifier = <vb.name=tableEntryPart,
> > >                       vb.type=OID,
> > >                       vb.value=0.1.instancePart>
> > >
> > Why not use vb.name=tablePart and save one more byte? The tableEntry sub-
> id
> > is always 1, so why not make it implicit?
>
> This may be a good idea.  Can't think of why not to do it.
> If I hear no objections, I'll try to work it into the next
> draft unless some glitch with that idea later comes to mind.
>
> >
> > Why not define a new type, OID-INDEX, which didn't have any restrictions
> on
> > the first byte, and save another byte?
>
> This first draft wanted to re-use existing PDU structures
> and types so as to get a feel for a "simple" way of doing
> things.  If we start defining new PDU structures, etc, then
> since the cat's out of the bag, there may be numerous approaches
> and PDU designs to maximize optimization.  I personally have no
> objection with new PDU structures and types and thingies if that's
> the WG consensus.  The current draft shows how to get a fairly
> efficient PDU out of existing structures without the drawbacks
> (whatever they may be) of an approach where we squeeze out the
> last few wasted bytes by defining highly optimized structures.
>
> Lauren