On 21/01/07, Magnus Fromreide <[EMAIL PROTECTED]> wrote: > AgentX: > Is an agentx master agent a proxy in the sense of RFC 2576/3584?
Not really. The main definition of a "proxy forwarder" is gi ven in RFC 3413, section 1.5. The critical aspect of that is that the forwarding application works with *complete* PDUs - it doesn't unpick an incoming request into two or more sub-requests, or stitch together several sub-responses into a single outgoing response. >From that perspective, our "proxy" implementation isn't strictly proxy forwarding at all. The CoExistence RFCs are also talking about different versions of SNMP. The AgentX protocol isn't quite SNMP - altough there are obvious similarities. I'll admit to using the spirit of RFC 2576 when it came to implementing the original AgentX support, but I'm not sure it's directly applicable. > If one look in RFC 2741 7.1.10 point 3 then it refers to RFC > 2089, but I am uncertain about the meaning of that. That seems to be referring to how a *sub*agent should deal with a request to send a notification, when that notification is provided in SNMPv1 form. I'd suggest that this is more to do with the handling of internal APIs, rather than proxying as such. > Another question is if one should update the proxy handling to > follow the recommendations of RFC 2576 or 3584 instead. Yes. > This do make a functional difference as the handling of varbinds > containing Counter64 values is changed between 2089 and > 2576/3584. Currently net-snmp seems to implement the 2089 rules. Can you clarify, please. I've had a quick skim through 2089 & 3584, and can't immediately spot what the difference might be. I'm probably missing something screamingly obvious - please enlighten me. > Proxy: > If a proxy as per RFC 2089/2576/3584 receives an > NOTIFICATION-PDU where snmpTrapOID.0 = ccitt.1 then the > enterprise field of an outgoing TRAP-PDU should contain what? > Additionally the same question but with iso.1 and > joint-iso-ccitt.1 is interesting as well. Juergen is clearly correct in saying that RFC 3584 doesn't cover this situation, and it should ideally be clarified.. But I'd have to ask whether this is ever likely to happen. (The trap, not the clarification!) The higher-levels of the .ccitt, .iso and .joint-iso-ccitt trees are administered by the relevant international bodies, who are the only people who could legitimately define an OID of this form. And I would be amazed if any standard NOTIFICATION TYPE object was ever defined with such an OID. So the only time this situation would occur would be following an abuse of the OID structure - someone defining MIB objects that they had no call to touch. In which case, they deserve all that's coming to them! > The current net-snmp handling of this case seems to be SIGSEGV, > so I suppose something have to be done. Crashing out is not a good idea, no! At the very least, I'd be inclined to log an error and discard the trap. Dave PS: Has anyone ever suggested to you that you've got a warped mind? :-) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
