Re: Protocol operations proposal deadline

>                          The agent should not have to deal
> with reconciling a potentially long list of conflicting option
> requests on a per varbind basis.

It wouldn't *have* to, but (speaking primarily as an agent developer),
I think it would be useful to have this sort of flexibility available
for those that wished to use it.
  It's not a fundamental requirement, sure - but it would be of use
in some circumstances.  I'm keen that it's at least considered,
rather than simply dismissed as unnecessary.


>                                    It's not that useful to
> request OID compression method A for varbind 1,3,5 and OID
> compression method B for varbind 2,4,6, and dontWrapColumns
> for varbind 1 and 7, etc.

OID compression is something of a red-herring here (as I said
to Wes last week).  The only reason I listed both compression
algorithms, is that I didn't want to pre-judge any decision about
which (if either) we should adopt.   Personally, I'd go for the
fuller functionality of the OID Delta compression, but with
a distinct tag for un-compressed OIDs (as discussed in the
OID Prefix compression draft).  I don't see any need to support
both in the long run - and I would probably expect that OID
compression would be applied to the whole PDU anyway.

  But dontWrapColumns and/or (even more so) fillHoles are
much more likely to be useful for particular areas of the
overall MIB tree than others.   E.g. when retrieving information
from a sparse table such as those augmenting the Host Resources
hrDeviceTable.   Using fillHoles in that sort of situation is
likely to be more trouble than it's worth.
  Whereas in some of the fuller HostRes tables, it's probably
much more useful.


>                          This also assumes that the NMS wants
> to micro-manage these requests.  I think the NMS developers
> want simple features that they can count on being implemented
> the same in every agent.

Maybe you're right - you've probably had more experience with
developing significant NMS applications than I have.  I'm just
trying to ensure that we don't try and second-guess the needs
of application developers, and end up losing useful functionality.

If a NMS developer wants to use extended features in an all-or-nothing
manner, they're still at liberty to do so, even with a micro-managable
architecture overall.  But if we decide to go for an all-or-nothing
approach, then that takes the option away from the developer.

Maybe that's a price worth paying - but (IMO) the increase in
simplicity does come at a price.

Dave


Dave