Re: [Fwd: Additional comments on draft-ietf-magma-mgmd-mib-12.txt]

Julian Chesterfield <[email protected]> Tue, 23 Sep 2008 11:20:13 +0100
Newsgroups gmane.ietf.magma
Message-ID <[email protected]>
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