Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)

[B Lukovic <[e-mail]>]

The point is that if the data is created over SNMP there is no way with 
proposed yang module
to preserve all info in the configuration.
When the agent is restarted (or new config committed), agent would 
"invent indices" and
this is, in my opinion, the problem (not functionally, agent would still 
function correctly).
But for SNMP manager monitoring the agent:
- index change would indicate change in configuration.
- getnext order could be different

A few examples:
Lets say target address table has N entries, all using the same set of 
parameters ( = one row in snmpTargetParamsTable).

Changing parameters for all N addresses:
SNMP - one row changed
NETCONF- N rows changed

Suspend communication with all N targets:
SNMP - delete one row in target params table (or set it to 
notInService), target address table preserves all targets
NETCONF- delete whole target list

Regarding proposed solutions
1) create "list targetparams" ...
basically map snmpTargetParamsTable to Yang,
complication could be solved as in SNMP mib, i.e. instead of leafref 
(forcing each target row to have valid params)
this could be just a string making "loose" coupling.

2) replace optional "notify-filter-profile" leaf with mandatory 
"param-name" leaf, ...
You are right, I overlooked that "list notify-filter-profile" should be 
updated with "param-name" as well

and a new one

3) add optional "leaf param-name" to "list target" so 
snmpTargetParamsName could be preserved
If missing, agent would generate appropriate index for snmpTargetParamsTable

I prefer option 1)

     Borislav

On 2/2/2014 4:09 PM, Martin Bjorklund wrote:
> Hi,
>
> B Lukovic <[e-mail]> wrote:
>> Hi,
>>
>> Re: target address/target params tables.
>> snmpTargetParamsName is not mapped into yang module.
>> This prevents agent from restoring snmp configuration after
>> restart/reload (assuming configuration is yang based).
>> E.g. agent is configured through snmp, "t1" and "t2" are rows in
>> targetAddress, "p1" is row in targetParams.
>> Both rows in targetAddressTable:
>>      "t1",...,"p1",...
>>      "t2",...,"p1",...
>> "point" to the same row in targetParamsTable:
>>      "p1", "v2c", "public"
>> saved as yang, targetParams row(s) are merged with rows of targetAddress:
>>      <target>
>>        <name>t1</name>
>>        ...
>>        <v2c>
>>          <security-name>public</security-name>
>>        </v2c>
>>      ..
>>      </target>
>>      <target>
>>        <name>t2</name>
>>        ...
>>        <v2c>
>>          <security-name>public</security-name>
>>        </v2c>
>>      ..
>>      </target>
>>
>> SNMP agent initialized from this config would not know the original
>> index ("p1") used in targetParamsTable.
>> One can argue that "locally arbitrary" in description of
>> snmpTargetParamsName allows agent to reassign indices,
>> but I believe this would lead to confusion.
> If data is created over NETCONF, the system will invent some index for
> the snmpTargetParamsName.  If the data is created over SNMP, the
> snmpTargetParamsName is simply not shown over NETCONF.
>
>
>> Possible solutions:
>> -  create "targetparams" list (index = leaf "name"), replace
>>     "params" choice with leaf "params" with type leafref { path
>>     "/snmp/targetparams/name" }
> This is certainly possible, but it introduces an extra level of
> indirection that complicates the model.
>
>> -  leave "params" choice, replace optional "notify-filter-profile"
>>     leaf with mandatory "param-name" leaf,
>>     explain relation between "param-name" and
>>     "notify-filter-profile/name" in description of "param-name"
> I don't think this solves the problem, since some reference is needed
> between the notify-filter-profile and the target-params.
>
>
>
> /martin
>