HI,

Good morning to you. My comments may be even stranger than normal
since it's 1:50am here.

On Thu, 28 Oct 2004, Dave Shield wrote:
> > First, thanks for updating the terminology. What the SNMP specs
> > say and what the code does (and what people generally say)
> > all concide.
Ooops, I think I meant "collide" here!

> I think that's being a little optimistic!
> What the Net-SNMP documentation and code refers to as "proxying"
> does *not* coincide with what the SNMP specs mean by that.   In fact,
> the model we use doesn't seem to be mentioned in RFC 3413 at all.
> 
> Hence I've introduced a distinction between "proxy forwarding"
> (passing on a complete request) and "proxy delegation" (passing
> on selected varbinds).
> 
> 
> > As to the security issue, the specs say that only the "target
> > system" and not the proxy does authorization (access control)
> > of a request.
> 
> Thanks - that's what I expected.
> 
> 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. Instead, if the manager is not limited by access
control, the manager can scan through both the target table
and the proxy table and work backwards to figure out the engineID
of the target. However, this can be ambiguous. (The manager
may not even know the IP address of the target!)  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. Also, to be able to communicate
with the proxy, the manager must have a valid user name
and either pass phrase or key pair.  When setting up the proxy
table the program (or person) can do engineID discovery of the
target, and must use that in configuring the proxy table.

> 
> >                         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? What I meant was the
value of fields contextName and contextEngineID fields in
a scopedPDU. The value of the contextEngineID is the engineID
of the target system. 

Hope this helps.

Regards,
/david t. perkins



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

Reply via email to