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

[Randy Presuhn <[e-mail]>]

Hi -

>From: Juergen Schoenwaelder <[e-mail]>
>Sent: Jan 9, 2014 4:41 AM
>To: Randy Presuhn <[e-mail]>
>Cc: [e-mail]
>Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
>
>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.

Yes you can, but that's irrelevant.  It's only a reference
to the group.  The vacmGroupName is an index of vacmAccessEntry.
That's where the group "exists".  We've already gone through
the argument about the ASI return codes.

>Once
>you assign a member to a group, it will always be associated with a
>group.

No.  It always *references* a group, which may or may not
actually exist.

> 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. :-{

That's a consequence of the decision to model what in SNMP
is a reference with containment in Yang.  I think it's an
unfortunate decision, but it's clear I'm the lone dissenter.

I really don't see any point in continuing this thread.
The arguments have been repeated multiple times, and it's
obvious that no one is convincing anyone.

Randy