> > So when a client first starts the engineID discovery process, > > it will receive the engineID and boot count/time values from the > > final (proxied) agent, rather than the intermediate (proxying) > > agent - correct?
> No - the manager "cannot" do engineID discovery of the target > system..... ..... To use proxies > as defined in the SNMP specs, someone has to configure the > target and proxy tables, and then provide the manager > the triple of the transport address of the proxy and the context > and engineID of the target. Hmmm - OK. I *think* I see..... But what about the boot information (count/time)? Presumably that *is* still discovered dynamically? And from the final agent rather than the proxy? > > > From the standpoint of the specs, > > > only the engineId, context, and varBindList from the PDU > > > is transfered "unaltered" from a manager to/from the target system. > > > > That's the snmpEngineId, rather than (actually as well as) the > > contextEngineId - correct? > You don't like my terminology usage? It's not that I don't like it - it's just ambigous. Within an SNMPv3/USM request, there are *two* "engineID" fields - the contextEngineId and the msgAuthoritativeEngineID (sorry - I'd got the wrong term in my head for the second one). I wasn't quite sure which one you were referring to (and guessed wrong). I'm probably conflating the USM-specific stuff with the generic SNMPv3 fields. Not having much experience of the other security models, it's a mistake that's very easy to fall into.... Dave ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
