Subject: group in group in MIB

From: Wes Hardaker <[email-masked]>
Date: 25 Apr 2001 16:16:53 -0700

Currently the IPSEC-POLICY-MIB doesn't support group-in-group.  The
original definitions of the tables that Mike Baer and I came up with
(sitting in a coffee shop) had more tables than the current MIB has
and implemented group-in-group semantics.  We then dropped the support
for it when writing the draft as it was decided it was too complex.
Then, in the Minneapolis meeting it was discussed again (in a wider
audience) and decided that it should be supported.  So, now I'm
bringing it to the widest of the audiences (the mailing list) and we
need to decide what to do and whether or not to support group-in-group
semantics.

Choices:

1) Leave it as is, where only rules can be inside groups.  This would
   deviate from the data model.

2) Add a new table defining what a group is supposed to contain
   (1=groups, 2=rules).  And another table containing the groups in a
   group if the type = 1.

3) merge the rules-in-groups/groups-in-groups table to be all one
   table containing merely a list of "names" in side a group, and then
   add one table like the first in #2 above that defined what a group
   was supposed to contain.

I'm not really happy with how the data model currently works, and it
makes this whole decision hard.  As defined a group can contain *only*
a set of groups *or* a set of rules.  This makes it impossible to
define a groupA that contains groupB, ruleC, groupD.  ruleC, in this
case, would have to be put into a group of its own (which is just
silly).

Also, what is the difference between GroupComponent and PartComponent
in the current IPsecPolicyGroupInPolicyGroup object?

It also makes no sense to me that the data model is defined such that
groups and rules can even exist with the same priority level.  I don't
think "two ContainedGroups with the same precedence is undefined" is
correct.  I think it should be simply illegal.

To do this properly though, the priority shouldn't be associated with
the group itself, but with whatever contains it.  IE, I'd like groupA
(above) to contain 1=groupB, 5=ruleC, 1000=groupD and still have a
second group optionally reorder them such that groupX contained
1=groupB, 20=groupD, 800=ruleC (last two swapped in precedence).

-- 
Wes Hardaker
NAI Labs
Network Associates