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

Martin Bjorklund <mbj@tail-f.com> Sun, 02 February 2014 21:09 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E295F1A00E8 for <netmod@ietfa.amsl.com>; Sun, 2 Feb 2014 13:09:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level:
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRot3Ko-SPga for <netmod@ietfa.amsl.com>; Sun, 2 Feb 2014 13:09:55 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 634C81A00A8 for <netmod@ietf.org>; Sun, 2 Feb 2014 13:09:55 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id BC3EC240C1E9; Sun, 2 Feb 2014 22:09:49 +0100 (CET)
Date: Sun, 02 Feb 2014 22:09:48 +0100
Message-Id: <20140202.220948.230573655.mbj@tail-f.com>
To: blukovic@ndt-inc.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <52D9B9CF.5010605@ndt-inc.com>
References: <014201cef85b$81260cf0$837226d0$@comcast.net> <20140111.101300.219049272.mbj@tail-f.com> <52D9B9CF.5010605@ndt-inc.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Feb 2014 21:09:57 -0000

Hi,

B Lukovic <blukovic@ndt-inc.com> 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