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

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Jul 2014 22:45:23 +0200

On Mon, Jun 09, 2014 at 11:41:05AM -0700, Randy Presuhn wrote:
> 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?

We previously removed the min-elements from the 'member' list and as
such it is not necessary to remove the group until all references to
it have been removed. The min-elements of the 'security-model' only
applies if an instance exists in the 'member' list, which seems to be
consistent with the way VACM works.

> (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?

An implementation may do garbage collection if no nonVolatile
references to a group exist anymore.

> (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?

In this case the configuration datastore would only store the group
without any members.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Jul 2014 22:48:24 +0200

On Tue, Jun 17, 2014 at 03:45:39PM +0200, Benoit Claise wrote:
> >>My feedback:
> >>-
> >>
> >>    The configuration data model in particular_targets_SNMP deployments
> >>    where SNMP runs in read-only mode and NETCONF is used to configure
> >>    the SNMP agent.  Nevertheless, the data model has been_designed_to
> >>    allow implementations that support write access both via SNMP and
> >>    NETCONF in order to interwork with SNMP-managed management
> >>    applications manipulating SNMP agent configuration using SNMP.
> >>
> >>    The YANG data model focuses on configuration.
> >>
> >>I don't understand what you mean by "targets" or "designed to"
> >>So you made some tradeoffs in the design? Is this the way we should
> >>understand this?
> >>If which one?
> >I think "in particular targets" should be read as in "will likely be
> >primarily used in". Or to say it in other words: If a deployment uses
> >SNMP to configure SNMP agents, then this data model may be of limited
> >value.
> I didn't read this way the first time. Maybe it's only me...
> >
> I didn't read this way the first time. Your new wording makes it clearer 
> to me.
> Again, maybe it's just me...

We tried to improve the text. Please check the next version of the
I-D.

> >>- At the beginning of VACM and SNMP, we faced one issue. Someone with a
> >>read-only community string could query the read-write community string.
> >>
> >>
> >>Router#sh run | i snmp
> >>
> >>snmp-server engineID local 000000090200009092827820
> >>
> >>snmp-server group v1group v1 read includeeverything
> >>
> >>snmp-server view includeeverything internet included
> >>
> >>snmp-server community _claise _RW
> >>
> >>snmp-server user _public _v1group v1
> >>
> >>...
> >>
> >>"snmpwalk -v 1 <Router> _public _internet.6.3.16 | grep _claise_"... you
> >>would be surprised
> >>
> >>Basically, the trick is that we need a default view on VACM.
> >>I see http://tools.ietf.org/html/rfc3415#section-7.4
> >>Do we need something specific in this draft to stress that issue?
> >I do not think that this document is the place to discuss how default
> >VACM rules should look like. This should go into a separate document
> >because this is not specific to the YANG data model but rather
> >specific to VACM.
> Yes, this is specific to VACM, but having an extra document just for 
> this might be an overkill.
> Adding one sentence in the Security Considerations would be make IMO.

We have added some additional text and we also tagged the community
such that NACM by default denies access.

The other editorial issues have been dealt with as well. There should
be an announcement of the new I-D shortly.

/js