Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00

I agree with Andy and Martin on the  approach. This looks like a good
set of requirements to start from. 

Dan
(speaking as a contributor) 

> -----Original Message-----
> From: netmod-bounces@ietf.org 
> [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman
> Sent: Friday, October 22, 2010 5:55 PM
> To: Martin Bjorklund; netmod@ietf.org; spakes@snmp.com
> Subject: Re: [netmod] Fw: New Version Notification for 
> draft-bjorklund-netmod-snmp-cfg-00
> 
> Hi,
> 
> I agree with Martin.
> There should be a new interfaces table that contains a 
> mapping to ifIndex so monitoring MIBs like RMON-MIB can be 
> used with SNMP, even though the config may be done through 
> NETCONF.  RMON is an example that supports complete 
> self-configuration through SNMP, but vendors has decided to 
> configure it through CLI anyway.
> 
> To understand the framework, we have to understand (at least) 
> how an individual feature would be realized within that framework.
> 
> Some requirements (IMO):
>   1) Ability to support easy to use YANG module for any 
> service or feature.
>      Global and per-interface inter-related components are the norm.
>      This must be clear in the data model.
>   2) Ability to continue retrieving interface-related 
> operational data with SNMP
>   3) Ability to also retrieve operational data with NETCONF
>      - mapping algorithm automatically translates any SMIv2 read-only
>        OBJECT-TYPE macro into functionally equivalent YANG 
> module, such that
>        predictable top-level YANG data nodes, suitable for 
> <get> retrieval,
>        are defined.
>   4) Ability to let vendors continue using their own 
> interface identification strings
>      - Provide optional YANG extension to let vendors 
> describe identifier string components
>   5) Ability to identify/configure parent and child interface 
> relationships, 
>      if there is some hierarchy within the interfaces. 
>      - other interface relationships such as hot-standby, 
> load-balancing, trunking 
>        should also be supported
>   6) Ability to pre-provision interfaces which are not 
> currently present.
>   7) Ability to enable or disable an interface
>   8) Ability to move child nodes from one interface to another
>      (e.g., move a service, replicate a service, line-card 
> changes slot)
> 
> 
> Andy
> 
> -----Original Message-----
> From: netmod-bounces@ietf.org 
> [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund
> Sent: Friday, October 22, 2010 2:11 AM
> To: netmod@ietf.org; spakes@snmp.com
> Subject: Re: [netmod] Fw: New Version Notification for 
> draft-bjorklund-netmod-snmp-cfg-00
> 
> Hi,
> 
> David Spakes <spakes@snmp.com> wrote:
> > At the very least, the working group should produce a 
> document that is 
> > the YANG equivalent to RFC 2863.  IMHO, it should exactly 
> mirror the 
> > existing objects, at least the ones that are not deprecated.
> 
> I disagree.  If all we do is put YANG syntax around existing 
> MIB objects, we haven't achieved anything.  We should 
> concentrate on interface configuration.  It is not important 
> to duplicate all interface counters etc.  One thing that *is* 
> important though is how a YANG interface configuration model 
> relates to the MIB.  (For example, how the interface name 
> maps to ifIndex.)
> 
> 
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 