[MIB-DOCTORS] Additional comments on draft-ietf-magma-mgmd-mib-12.txt

["Bert Wijnen \(IETF\)" <[e-mail]>]

I am not subscribed to the magma mailing list.
Hopefully Brian can forward.

In the past, I had only done some MIB SYNTAX checking (with SMICng) on the 
earlier
versions of this MIB document. The SYNTAX errors I then found have now been 
fixed.
Thanks.

I never did a complete MIB review for this MIB module. Neither did I do so 
this time.
I believe that full MIB doctor review was done by Dave Thaler. I assume he 
will
check if his comments have been properly addressed.

I now happend to browse through the MIB module some more, and I am somewhat
suprised by the many MODULE-COMPLIANCE staments. But not only suprised. I
am also confused.

For example, I am  wondering how the following 2 statements differ. I can 
see in
the DESCRIPTION clauses some differences, but none of that is 
machine-readable.

  mgmdIgmpV1HostReadMIBCompliance MODULE-COMPLIANCE
     STATUS  current
     DESCRIPTION
            "A read-only compliance statement for hosts running IGMPv1
            [RFC 1112] and implementing the MGMD MIB. IGMPv1 hosts must
            support the IPv4 address type."
     MODULE  -- this module
     MANDATORY-GROUPS { mgmdHostBaseMIBGroup }
     GROUP mgmdHostOptMIBGroup
     DESCRIPTION
            "Write access is not required."
     ::= { mgmdMIBCompliance 1 }

  mgmdMldV1HostMIBCompliance MODULE-COMPLIANCE
     STATUS  current
     DESCRIPTION
            "A read-only compliance statement for hosts running MLDv1
            [RFC 2710] and implementing the MGMD MIB. MLDv1 hosts must
            support the IPv6 address type."
     MODULE  -- this module
     MANDATORY-GROUPS { mgmdHostBaseMIBGroup }
     GROUP    mgmdHostOptMIBGroup
     DESCRIPTION
            "Read-only access required."
     ::= { mgmdMIBCompliance 8 }

But even worse, In the two OBJECT GROUPS that play a role here, I see:

   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 }

  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 }

First, in principle, you do not specify in the DESCRIPTION clasue of an 
OBJECT-GROUP
if they are "optional or not". They are a GROUP, nothing more. If they are 
mandatory
or optional, that is specified in the MODULE-COMPLIANCE. They could be 
optional
in one MODULE-COMPLIANCE and MANDATORY in another.
I personally would even prefer the "Opt" is not part of the name of the 
group.

Second,   if they are MAX-ACCESS read-only in the OBJECT definition, then 
that
is what it is. If they have MAX-ACCESS read-write or read-create on the 
OBJECT
definition, then they could be read-only for a module-compliance, but again, 
that
is specified in the MODULE-COMPLIANCE statement in the OBJECT clause
underneath a MANDATORY-GROUPS or GROUP clause in the MODULE-COMPLIANCE.
Again, they could be OK in read-only mode in one MODULE-COMPLIACNE and
read-write in another.

Now... the object in the first group does have a read-create object. To make 
a
read-only implementation compliant, you would do so by adding a OBJECT 
clause
to the MODULE-COMPLIANCE, see below.

My third problem is that it is not clear how you want this implemented. Does 
it
mean that for this MODULE-COMPLIANCE you only have to have the
rowstatus object and none of the otehr objects in the table?

The objects in the 2nd group all happen to be read-only objects. So although 
the
comment about them being read-only objects does not harm, I think I would 
not
state so in the OBJECT-GROUP DESCRIPTION clause. But that is a NIT
And there is certainly not a need to state that "write access is not 
required"
in the MODULE-COMPLIANCE. The objects have MAX-ACCESS of read-only. so !!!

You speak about ipv4 or ipv6 support, and such can also be specified
in OBJECT clauses (so it become machine readable), see below.

I wonder if
    mgmdIgmpV1HostReadMIBCompliance MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
            "A read-only compliance statement for hosts running IGMPv1
            [RFC 1112] and implementing the MGMD MIB. IGMPv1 hosts must
            support the IPv4 address type."

Means that only IPv4 needs to be supported, or that both IPv4 AND IPv6 must 
be
supported? My understanding from that text would be "only IPv4".
You may  want to clarify that. If you look at my module-compliance
suggestion below, then you can see that that makes it much clearer
(I have stated it how I understood it).

Same for
   mgmdMldV1HostMIBCompliance MODULE-COMPLIANCE
      STATUS  current

      DESCRIPTION
            "A read-only compliance statement for hosts running MLDv1
            [RFC 2710] and implementing the MGMD MIB. MLDv1 hosts must
            support the IPv6 address type."

Does that mean ONLY IPv6 or both IPv4 and IPv6?


So to better document the module compliance, I would do something like:

mgmdIgmpV1HostReadMIBCompliance MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
            "A read-only compliance statement for hosts running IGMPv1
            [RFC 1112] and implementing the MGMD MIB. IGMPv1 hosts must
            support only the IPv4 address. In the index, this means
            for object mgmdHostInterfaceQuerierType

              OBJECT     mgmdHostInterfaceQuerierType
              SYNTAX     InetAddressType {ipv4(1)}
            "
    MODULE  -- this module
    MANDATORY-GROUPS { mgmdHostBaseMIBGroup }
    OBJECT mgmdHostInterfaceStatus
    SYNTAX RowStatus {active(1)}
    MIN-ACCESS read-only
    DESCRIPTION "read-write or read-create access is not required
                 and only the value 'active(1)'  needs to be supported"
    GROUP mgmdHostOptMIBGroup
    DESCRIPTION
            "Supporting this optional group can be especially useful
            in an environment with a router which does not support
            the MGMD MIB."
    ::= { mgmdMIBCompliance 1 }

Before I go and try to do the other MODULE-COMPLIANCE statements
(or help with them), I would first like to hear the author/editor opinion
and the opinion of the WG.

Bert Wijnen 


_______________________________________________
MIB-DOCTORS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mib-doctors