[MIB-DOCTORS] Weird OBJECT-GROUPS (grouping) in draft-ietf-magma-mgmd-mib-12.txt

When trying to understand the MODULE-COMPLIANCES a bit better I
had to take a closer look at the OBJECT-GROUPS as well.

And I must say I find it very weird to see a table mgmdHostInterfaceTable
that has this sequence of objects:

  MgmdHostInterfaceEntry ::= SEQUENCE {
  *  mgmdHostInterfaceIfIndex               InterfaceIndex,
  *  mgmdHostInterfaceQuerierType           InetAddressType,
      mgmdHostInterfaceQuerier               InetAddress,
      mgmdHostInterfaceStatus                RowStatus,
      mgmdHostInterfaceVersion               Unsigned32,
      mgmdHostInterfaceVersion1QuerierTimer  TimeTicks,
      mgmdHostInterfaceVersion2QuerierTimer  TimeTicks,
      mgmdHostInterfaceVersion3Robustness    Unsigned32
  }

Those with an * in front of them are the INDEX objects.

I then see OBJECT-GROUPS that have one or more objects from this table
as follows:

mgmdHostBaseMIBGroup OBJECT-GROUP

    OBJECTS { mgmdHostInterfaceStatus }
    STATUS  current
    DESCRIPTION
            "The basic collection of objects providing management of
            MGMD version 1, 2 or 3 for hosts."
    ::= { mgmdMIBGroups 1 }

mgmdV2IgmpHostWriteMIBGroup OBJECT-GROUP
    OBJECTS { mgmdHostInterfaceVersion
            }
    STATUS  current
    DESCRIPTION
            "A collection of additional read-create objects for
            management of IGMP version 2 in hosts for MGMD version
            2 compliance."
    ::= { mgmdMIBGroups 4 }

mgmdV2IgmpHostReadMIBGroup OBJECT-GROUP
    OBJECTS { mgmdHostInterfaceVersion1QuerierTimer
            }
    STATUS  current
    DESCRIPTION
            "A collection of additional read-only objects for
            management of IGMP version 2 in hosts for MGMD version
            2 compliance."
    ::= { mgmdMIBGroups 5 }

mgmdHostOptMIBGroup OBJECT-GROUP

    OBJECTS { mgmdHostCacheLastReporter, mgmdHostCacheUpTime,
              mgmdHostInterfaceQuerier, mgmdInverseHostCacheAddress }
    STATUS  current
    DESCRIPTION
            "A collection of optional read-only objects for MGMD hosts.
            Supporting this group can be especially useful in an
            environment with a router which does not support the MGMD
            MIB."
    ::= { mgmdMIBGroups 6 }

mgmdV3HostWriteMIBGroup OBJECT-GROUP
    OBJECTS { mgmdHostInterfaceVersion3Robustness }
    STATUS  current
    DESCRIPTION
            "A collection of additional read-create objects for
            management of MGMD version 3 in hosts."
    ::= { mgmdMIBGroups 12 }

mgmdV3HostReadMIBGroup OBJECT-GROUP
    OBJECTS { mgmdHostInterfaceVersion2QuerierTimer,

              mgmdHostCacheSourceFilterMode,
              mgmdHostInterfaceVersion3Robustness,
              mgmdHostSrcListExpire
            }
    STATUS  current
    DESCRIPTION
            "A collection of additional read-only objects for
            management of MGMD version 3 in hosts."
    ::= { mgmdMIBGroups 13 }

WHat seems so weird to me is the fact that all these objects are located in 
one
single table (so they seem to belong together) and yet they pop up in many 
differnt
OBJECT groupings as if they have nothing to do with each other. I wonder 
what the
explanation is for this.

I have already mentioned in an earlier email that you SHOULD NOT name
groups xxxReadXxxGroup or xxxWirtexxxGroup or xxxOptxxxGroup nor should
you speak about read-only or read-write or optional objects in the 
DESCRIPTION
clauses of OBJECT-GROUPS. if the objext are read or write, that is something
defined in the MAX-ACCESS clause on the OBJECT-TYPE and in the
MIN-ACCESS clause in the OBJECT clause of a MODULE-COMPLIANCE.
Same for the fact that objects are optional or not. That is done through
the MODULE-COMPLIANCE< not through OBJECT-GORUPing.

Bert Wijnen 

_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors