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

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Jan 07, 2014 at 09:26:36AM -0800, Randy Presuhn wrote:
> Hi -
> 
> >From: Martin Bjorklund <[e-mail]>
> >Sent: Jan 6, 2014 11:13 PM
> >To: [e-mail]
> >Cc: [e-mail]
> >Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> >
> >"Randy Presuhn" <[e-mail]> wrote:
> >> Hi -
> >> 
> >> > From: "Martin Bjorklund" <[e-mail]>
> >> > To: <[e-mail]>
> >> > Cc: <[e-mail]>
> >> > Sent: Monday, January 06, 2014 1:53 PM
> >> > Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> >> ...
> >> > What do you mean by a "group which does not exist"?  
> >> > 
> >> > Maybe you can provide an example (MIB) configuration that is not
> >> > possible to express in the YANG model?  (assuming also that we remove
> >> > the min-elements constraint from the "member" list).
> >> 
> >> Sure.  An instance of  vacmGroupName with value "TBD",
> >> when no entry exists in vacmAccessTable with such a value.
> >> Note that this is explicitly permitted by the definitions of
> >> vacmGroupName.
> >
> >This is expressable, see below.
> >
> >> > > If VACM has been configured with one or more users referring
> >> > > to groups that don't happen to exist at the moment, a fairly
> >> > > reasonable thing to do, the Yang/Netconf interface cannot
> >> > > represent that configuration.
> >> > 
> >> > If you mean an entry in vacmSecurityToGroupTable with a vacmGroupName
> >> > that does not exist in vacmAccessTable, this is possible to express
> >> > with the YANG model.
> >> 
> >> Cool.  I couldn't see how the Yang model would allow it, since the
> >> list "member" 
> >> is contained by the list "group".  Could you explain how one could create
> >> a "member" without creating the containing "group"?
> >
> >That's not what I wrote.  Let's be concrete.
> >
> >  vacmGroupName.3.3.b.o.b = TBD
> >  vacmGroupName.3.5.a.l.i.c.e = TBD
> >
> >can be represented as
> >
> >  <group>
> >    <name>TBD</name>
> >    <member>
> >      <security-name>alice</security-name>
> >      <security-model>usm</security-model>
> >    </member>
> >    <member>
> >      <security-name>bob</security-name>
> >      <security-model>usm</security-model>
> >    </member>
> >  </group>
> 
> This is where's where you lose me.  In the VACM
> model the group does not exist, but in the Yang model
> it does.

But you can't delete vacmGroupName.3.3.b.o.b with SNMP either. Once
you assign a member to a group, it will always be associated with a
group. In other words, a member who does not belong to any group can
only exist as part of setting up group members, e.g. as part of
filling out a row. Yes, such incomplete entries may exist for a long
time if you activate the row in SNMP. Using the YANG interface, you
can't create them. If we were to change the YANG model to allow this,
we would likely end up with a mechanism to unassign members from any
groups, which I think is not possible using VACM. :-{

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>