Re: Clarification reqd

Hi ,

        I think I mixed up things in my previous mail. I'll try to frame 
it better:* *I have refered to * DEFVAL *as defined in RFC1212. 


        Now consider the following scenario:

                        The natConfTable is used to enable NAT on the 
eth0. This is done by using the DEFVAL of ' 'H for the 
natConfAddrMapName while creating that row. Now if a snmpwalk is 
performed on the natConfAddrMapTable, even with just the "default index 
value" mapping rows can be returned. The returned entries are now 
returned with primary index as ' 'H and secondary index as the value of 
natConfAddrMapIndex( 1 .. 2147483647).
                        Now here is the problem I see: Repeat the above 
steps for eth1.  ie Enable  NAT for eth1(Here also  natConfAddrMapName 
is specified as the DEFVAL). Now if a walk is performed on the 
natConfAddrMapTable there will be a problem in retuning the rows, as 
sorting based on the primary index and secondary index will not be 
possible. ie there could be two entries for each  The problem originated 
since the DEFVAL clause does not seem to provide a correct default. 
Ofcourse the user should have the understanding to use unique values for 
each entry created in the natConfTable. Please let me know your views on 
this and if the scenario is valid, a possible solution for the same.

                        An associated problem with the 
natConfTable.natConfEntry.natConfAddrMapConfigName is that. This table 
decides the Index for the natConfAddrMapTable. Now, assuming that the 
two tables are tightly tied up, any change in the 
natConfTable.natConfEntry.natConfAddrMapConfigName  in the first table 
will result in changes in the second table. I dont believe this is a 
consistent thing to do. Why can't the index be predecided when we know 
that the index is just to indicate to the Manager the interface to which 
the mapping belongs. The primary index in the natConfAddrMapTable could 
be the primary index of the natConfTable. Is there any other purpose in 
having it as a string ? Please highlight the purpose/advantages in 
having it as a string.


Thanks and Regards,
Sam

Sam K. Sankoorikal wrote:

> Hi Rajiv,
>
>         I have a specific query on the natConfAddrMapName[Seems to a 
> be a complex index]: Is there some convention[~default] to be followed 
> when using this index while returning a row of this table?
>         This a scenario where the natConfAddrMapName may not be have 
> yet been given a name by any manager and NAT / NAPT is already enabled 
> on an interface. As a result, there are rows already present in this 
> table, based on mapping created on the fly by the NAT module, through 
> some UI configuration. Is it OK/Safe if the Agent decides to use a 
> name it finds convenient and thus be able to return to NAT mapping to 
> any manager querying it ?
>
> Some relate questions:
>
> 1. Does the agent also have to store the same value in the 
> "natConfTable.natConfEntry.natConfAddrMapConfigName".?
>
> 2. Can a Manager change only 
> natConfTable.natConfEntry.natConfAddrMapConfigName and what is the 
> effect on the natConfAddrMapEntry.natConfAddrMapName. This leads to an 
> inconsistent state in SNMP if left to the Manager.
>
>
> Thanks and Regards,
> Sam.
>