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
_______________________________________________
magma mailing list
magma@...
https://www.ietf.org/mailman/listinfo/magma
