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

[Randy Presuhn <[e-mail]>]

Hi -

>From: Martin Bjorklund <[e-mail]>
>Sent: Jan 7, 2014 9:34 AM
>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]>
>> >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.
>
>In VACM the group does not exist in vacmAccessTable, and in the YANG
>model there are no entries in the group/access list.  So it is
>equivalent.
>
>BTW, 3415 says
>
>   Within the View-Based Access Control Model, a
>   groupName is considered to exist if that groupName is listed in the
>   vacmSecurityToGroupTable.
>
>and
>
>   A group is a set of zero or more <securityModel, securityName> tuples
>   on whose behalf SNMP management objects can be accessed.  A group
>   defines the access rights afforded to all securityNames which belong
>   to that group.  The combination of a securityModel and a securityName
>   maps to at most one group.  A group is identified by a groupName.
>
>So it seems to me that the group TBD actually exists in this case even
>in VACM.
>
>
>/martin

That still seems like a badly twisted mapping to me,
confusing a reference to an entity with the entity itself.
Look at the indexing structure.

But it's also clear that I'm the only one who thinks so.
We're just repeating arguments that have already been made,
so I don't think we're going to convince each other.
I think the chairs will just have to declare (rough) consensus
on the point and move on.

Randy