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

From: Randy Presuhn <[email-masked]>
Date: Mon, 9 Jun 2014 11:41:05 -0700 (GMT-07:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Jun 7, 2014 12:02 AM
>To: Benoit Claise <[email-masked]>
>Cc: [email-masked], NETMOD Working Group <[email-masked]>
>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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Jun 2014 15:49:58 +0200

Dear authors, document shepherd,

Should Randy's point be discussed in this document?

Regards, Benoit
> .