Thanks Bert,
Comments inline.
Brian Haberman wrote:
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.
The additional Module-compliance statements were added in response to a
request to split out the read-only/read-create access requirements for
both MLD and IGMP hosts, hence the somewhat large matrix of options.
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 }
The difference is the relevance to hosts utilising the IGMP vs MLD
protocol.
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.
Ack. No objections.
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.
Ack.
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.
Thx, the example below looks fine.
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?
That's correct.
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
!!!
Good point.
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?
It means that only IPv4 needs to 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?
It means that either may be supported, but at least IPv6 must be
supported.
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 }
This looks fine, thanks for the pointers.
Before I go and try to do the other MODULE-COMPLIANCE statements
(or help with them),
Please do, we're keen to get this finished up and everyone in agreement.
Thanks,
Julian