IETF Logo Mail Archive

Re: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05

Randy Presuhn <randy_presuhn@mindspring.com> Mon, 09 June 2014 18:41 UTC

Return-Path: <randy_presuhn@mindspring.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 AD1921A02B7 for <netmod@ietfa.amsl.com>; Mon, 9 Jun 2014 11:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level:
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 nVktjNhsO3vT for <netmod@ietfa.amsl.com>; Mon, 9 Jun 2014 11:41:36 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 458E81A02A6 for <netmod@ietf.org>; Mon, 9 Jun 2014 11:41:35 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=BZGajCY4wYEhjrq+bhk//FGulasAI3gLj4i+fTg6ZHIr0hOnpfTaqUS4IC2/LKUP; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.29] (helo=mswamui-cedar.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1Wu4VF-0001T4-Cy; Mon, 09 Jun 2014 14:41:05 -0400
Received: from 76.254.54.24 by webmail.earthlink.net with HTTP; Mon, 9 Jun 2014 14:41:05 -0400
Message-ID: <14507864.1402339265349.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net>
Date: Mon, 09 Jun 2014 11:41:05 -0700
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Benoit Claise <bclaise@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd81e6b07bfe95586fab1decfc976a7c5cbe350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.29
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jTHj6lRDtxZiUq1BoL7w4JO4Uv0
Cc: draft-ietf-netmod-snmp-cfg@tools.ietf.org, NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn <randy_presuhn@mindspring.com>
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: Mon, 09 Jun 2014 18:41:38 -0000

Hi -

>From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
>Sent: Jun 7, 2014 12:02 AM
>To: Benoit Claise <bclaise@cisco.com>
>Cc: draft-ietf-netmod-snmp-cfg@tools.ietf.org, NETMOD Working Group <netmod@ietf.org>
>Subject: Re: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05
...
>Concerning "designed to": The data model has been designed to cover
>everything that the SNMP configuration models describe. It allows an
>implementation that supports both configuration via NETCONF and
>configuration via SNMP. The details are discussed in section 3.2.

When SNMP is used to change the value of an
instance of vacmGroupName in the vacmSecurityToGroupTable,
some side-effects will need to happen in the netconf datastores,
due to the decision to model the information differently.
I know this has come up before, but it's unclear to me what
needs to happen on the netconf server side in a couple
of specific cases:

(1) If the vacmGroupName has a value that hasn't been seen before,
a "group" obviously needs to be created as a side-effect in
netconf land.  What's less obvious is what happens to the
old "group" in the case where no other entries in the
vacmSecurityToGroupTable still have that particular value
for vacmGroupName.  Is it to be automagically deleted
because the security-model's min-elements constrainted
would otherwise be violated?

(2) Likewise, when the value of the StorageType of an entry
in vacmSecurityToGroupTable is modified from nonVolatile
to volatile, does similar "garbage collection" have
to happen as a side-effect?

(3) When the entry in vacmSecurityToGroupTable is volatile,
and some (but not all) of the corresponding vacmAccessTable
entries are nonVolatile, what happens in the netconf datastores?

Randy

v2.23.0 | Report a Bug | By Email