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

[B Lukovic <[e-mail]>]

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.

Possible solutions:
-  create "targetparams" list (index = leaf "name"), replace "params" 
choice with leaf "params" with type leafref { path 
"/snmp/targetparams/name" }
-  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"


     Borislav


On 1/11/2014 4:13 AM, Martin Bjorklund wrote:
> Hi,
>
> "ietfdbh"<[e-mail]>  wrote:
>> Hi,
>>
>> I apologize for not getting a review done earlier in the process.
>>
>> After a quick comparison between rfc3413 and ietf-snmp-common, I have some
>> comments and concerns.
>>
>> I question the statement in the Introduction, "The configuration model is
>> consistent
>>
>>     with the MIB modules defined in ."
>>
>>
>> 1) I am concerned that StorageType is not modeled.
>>
>> I understand the different persistence approaches; I don't consider
>> StorageType to be only about persistence of dynamically-set data, and which
>> datastore to use, but rather reporting on implementation choices.
>>
>> Looking at RFC3413 as an example, I would think an operator might want to
>> know whether an SnmpTargetAddrEntry is implemented in RAM or ROM. Being able
>> to read the StorageType of the existing table could save a client the chore
>> of weeding out rows of configuration data that are sure to fail, if the row
>> is not writable. At a minimum, I think this should be reported as
>> operational state, so an operator can determine why a particular
>> configuration attempt is failing.
> Operational state is out of scope for this draft.
>
> The RFC 6643 translated MIB modules can be used.
>
>
>> 2) I am concerned that RowStatus is not modeled. Rowstatus objects
>> constrains how configuration can be performed on the row. For example,
>> snmpTargetAddrRowStatus states that TDomain and TAddress may not be modified
>> if the value of RowStatus is active(1). I assume there was a very good
>> reason for putting that constraint into this table. Does NETCONF get to just
>> ignore that constraint, and overwrite the values of TDomain and TAddress
>> even if RowStatus is active?
>>
>> This has nothing to do with persistence across reboots; it has to do with
>> controlling how the row can be modified at runtime, and how a row can be
>> created and deleted. Some of these constraints are to ensure that changes
>> cannot be made in the middle of an operation, thereby affecting the
>> operation. Some of these constraints relate to security, such as the control
>> of who gets notified of a security violation. Having NETCONF
>> create/modify/delete rows while ignoring the RowStatus rules would seem to
>> create both operational and security risks.
> RowStatus is an SNMP-specific construction.  A row that is not active
> exists in the SNMP agent, but is "unavailable for use by the managed
> device".
>
> In NETCONF the transaction can be much bigger than traditional SNMP;
> which means that a client can send everything in one operation, and
> does not have to carefully construct multiple PDUs to first inactivate
> some rows, then modify the values, then re-active the rows.
>
>> 3) "When the snmpTargetAddrParams object contains a reference
>>
>>                to a non-existing snmpTargetParamsEntry, this choice does
>>                not contain any case, and vice versa.";
>>
>> Is this consistent with RFC3413:
>>
>> "            Until instances of all corresponding columns are
>>              appropriately configured, the value of the
>>              corresponding instance of the snmpTargetAddrRowStatus
>>              column is 'notReady'.
>>
>>              In particular, a newly created row cannot be made
>>              active until the corresponding instances of
>>              snmpTargetAddrTDomain, snmpTargetAddrTAddress, and
>>              snmpTargetAddrParams have all been set."
>>
>> Are all required objects in target and params required when using NETCONF to
>> create a row?
> Yes.
>
>> 3) From RFC3414: "The use of usmUserSpinlock is to avoid conflicts with
>> another SNMP command generator application which may also be acting on the
>> usmUserTable." The YANG model doesn't support spinlock; how does Netconf
>> avoid conflicts with other command generators working on the usmUserTable?
>> Let's assume a command generator has started building the necessary tables,
>> using spinlock to differentiate their processes from other processes, and
>> Netconf interrupts that process.
> This is a good point, thank you for catching it!
>
> Implementations allowing both write access via SNMP and NETCONF should
> be recommended (required?) to bump the spinlock when NETCONF modifies
> the relevant parts of the SNMP tables.
>
> (this applies of course to all (three) spin locks in these mibs)
>
>> 4) Is there a reason the example for configuring the engine in appendix A
>> uses ip=0.0.0.0 and ip=::? I didn't notice any special semantics associated
>> with this value in the description of <ip> or inet:ip-address. RFC5737
>> contains blocks of addresses reserved for documentation purposes.
> These addresses are used in Appendix A.1 where it shows a listening
> endpoint.  0.0.0.0 and :: are the IP any addresses used to listen on
> any interface.
>
> But we can change this to a documention-special address if the example
> becomes more clear this way.
>
>> 5) The security implications of not using the RFC3414 method for cloning and
>> key change are not discussed.
> NETCONF generally over a secure and encrypted transport (this is
> pointed out in the Security Considerations section) hence the SNMP
> cloning mechanism is not needed.  I am not sure what kind of text you
> are looking for.
>
>> 6) I think the examples could benefit from a few comment lines to indicate
>> why the choice of values, such as the value of engineID, the values of IP
>> addresses, and the value of the key in the usm config example.
> The keys and the engineID have been copied from RFC 3414.
>
>> 7) I am having some difficulty understanding the purpose of the YANG snmp
>> models.
> The same purpose as any YANG or MIB module - to provide a standardized
> way to manage the underying subsystem if NETCONF/YANG or SNMP/MIBs are
> used.
>
>> I would assume one might use the YANG model with NETCONF to
>> initially configure the SNMP subsystem on a device, and then to subsequently
>> use SNMP based on that configuration.
> This might be one scenario.
>
>> But the YANG model is omitting objects
>> that are REQUIRED for some aspects of SNMP to work properly. For example, as
>> far as I can tell, an SNMP admin (or security admin or SNMP application)
>> could not perform a keychange operation using SNMP because the YANG model
>> would not have initialized the necessary SNMP objects, such as
>> clonefrom.
> usmCloneFrom is never intialized - when read it is always
> zeroDotZero.  It is only used when a new user is created over SNMP.
>
> So your statement that keychange cannot be done is not correct.
>
>> But other than to say that the YANG doesn't include some of the objects
>> defined in the MIB, there is no discussion of the operational and security
>> implications of not configuring these objects for subsequent use in SNMP.
>>
>> I guess the answer is that if you use Netconf and YANG to initially
>> configure USM, then you can only manage it in the future using NETCONF and
>> YANG; it seems that it stops being manageable via SNMP.
> No.
>
>> SNMP-manageable
>> security and SNMP-manageable access control were important goals of the
>> SNMPv3 WG, as documented in RFC3411 design requirement sections A.1.2 and
>> A.4.
>>
>> I question whether this document should be allowed to advance given this
>> lack of complete configuration of the targeted SNMP MIB modules,
> Well, we don't think the models lack anything...
>
>> but if it
>> is, then I think it is really important to spell out the implications in an
>> operational considerations section, and in the security considerations
>> section.
> Another scenario are deployments (operators told the IETF that they
> exist long ago) where SNMP agents run in read-only mode and other
> mechanism (typically proprietary CLIs) are used to configure the SNMP
> agent. This YANG configuration data model clearly targets such
> deployments (that apparently do exist). It still allows to interwork
> with SNMP-managed applications.
>
>
> /martin
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>