Re: [IETFMIBS] RFC 3584 usage of snmpTargetAddrTable

["Eduardo Cardona" <e.cardona at CableLabs.com>]

Jurgen thanks for the reply

It appears to me REF 3484 defines a Community Name mapped to a security
name for MP access level and the transport tag points to the source
access control (transport Addr/Mask ) (I believe not the original
intention of the snmpTargetAddrTable). 

Then, the SnmpTargetAddrParams point back again to a Security Name in
snmpTargetParamsTable (?).
 
For me SnmpTargetAddrParams is clear when used in notifications and
probably in Proxy systems. 

RFC 3584 does not explain the role of SnmpTargetAddrParams. My thought
was that SnmpTargetAddrParams in SNMPv1, SNMPv2c responses is not used
as the agent responds using the MP model from the request message.

See RFC 3584 
5.2.2.  Generating An Outgoing Response

   There is no special processing required for generating an outgoing
   response.  However, the community string used in an outgoing response
   must be the same as the community string from the original request.
   The original community string MUST be present in the
   securityStateReference information of the original request. 

Moreover, different community names associated with different security
names can point to the same transport tag, therefore the
snmpCommunityTable security name will not match the securityName in the
snmpTargetParamsTable entry. 

Let me know it that clarifies the question

Thanks

Eduardo

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:j.schoenwaelder at jacobs-university.de] 
Sent: Monday, July 14, 2008 12:33 PM
To: Eduardo Cardona
Cc: ietfmibs at ietf.org
Subject: Re: [IETFMIBS] RFC 3584 usage of snmpTargetAddrTable

On Mon, Jul 14, 2008 at 10:37:29AM -0600, Eduardo Cardona wrote:

> I think the syntax constrain of snmpTargetAddrParams does not cover 
> the usage of snmpTargetAddrTable in RFC 3584 where snmpTargetAddrTable

> does not represent a SNMP notification target but a SNMPv1/v2c 
> transport address/mask pair for SNMP Snmpv1/v2c coexistence with
SNMPv3 framework.

Why do you think so?

> Existing definition RFC 3413,
> 
> snmpTargetAddrParams OBJECT-TYPE
>     SYNTAX      SnmpAdminString (SIZE(1..32))
>     MAX-ACCESS  read-create
>     STATUS      current
>     DESCRIPTION
>         "The value of this object identifies an entry in the
>          snmpTargetParamsTable.  The identified entry
>          contains SNMP parameters to be used when generating
>          messages to be sent to this transport address."
>     ::= { snmpTargetAddrEntry 7 }
> 
> 'intended' syntax
> snmpTargetAddrParams OBJECT-TYPE
>     SYNTAX      SnmpAdminString (SIZE(0|1..32))
>     MAX-ACCESS  read-create
>     STATUS      current
>     DESCRIPTION
>         "The value of this object identifies an entry in the
>          snmpTargetParamsTable.  The identified entry
>          contains SNMP parameters to be used when generating
>          messages to be sent to this transport address.
>          The zero-length string is applicable to entries in this
>          table related to RFC 3584."
>     ::= { snmpTargetAddrEntry 7 }

I fail to see how the added sentence provides clearity. An
snmpTargetAddrEntry identifies a transport endpoint with associated
parameters while an snmpTargetParamsEntry adds to it the SNMP message
processing model to be used, the security model to be used, etc. You
need all this for SNMPv1 or SNMPv2c. Perhaps what is missing is just an
example how these tables work together but I doubt someone will revise
RFC 3584 for that purpose.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
IETFMIBS mailing list
IETFMIBS at ietf.org
https://www.ietf.org/mailman/listinfo/ietfmibs