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.
> -----Original Message-----
> From: Lauren Heintz [mailto:email@example.com]
> Sent: Tuesday, May 1, 2001 19:57
> To: Robert Story
> Cc: firstname.lastname@example.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-
> > 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
> > 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.