Subject: Re: [netmod] snmp configuration data model charter addition

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 2 Aug 2011 19:43:59 -0700

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, July 29, 2011 5:33 AM
> Subject: Re: [netmod] snmp configuration data model charter addition
>
> "Randy Presuhn" <[email-masked]> wrote:
> > Perhaps this is what is meant?
> >    5. Data model for configuring SNMP engines. The model must be
> >        capable of representing all SNMP engine configurations possible
> >        with the standard SNMPv3 MIB modules.
> 
> This is not exactly what the current document tries to do.  It is
> capabale of representing all "usable" configurations, but for example,
> the MIBs allow an snmpTargetParamsEntry with:
> 
>   snmpTargetParamsMPModel = 0
>   snmpTargetParamsSecurityModel = 3
> 
> but this is not possible in the YANG model.
> 
> Here's another example: (copy&pasting from a comment...)
> 
> # In some cases, the YANG model imposes stricter constraints on valid
> # configurations than the corresponding MIB model.  For example, the
> # leaf "/snmp/community/tag" is a leafref, which means that in a valid
> # configuration, it MUST refer to an existing target tag, as defined in
> # ^RFC6020^.  There is no such constraint the MIBs.

Consider this case:
   Such a configuration has been put in place using SNMP or other means.
   (a)  What happens when a NETCONF client attempts to
          retrieve that configuration?
   (b)  What happens in a configuration backup / restore scenario when
          NETCONF is the protocol used to shovel the information around
          using this model?

It seems to me that this fails to meet one of the most basic configuration
management use cases.

Randy