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

bcc: mib-doctors

Again, I am not subscribed to the magma WG list, so pls forward.
And if people want me to see responses, they better copy me explicitly.

See inline

----- Original Message ----- 
From: "Julian Chesterfield" <[email protected]>
To: <[email protected]>
Cc: "Brian Haberman" <[email protected]>; <[email protected]>
Sent: Tuesday, September 23, 2008 12:20 PM
Subject: Re: [Fwd: Additional comments on draft-ietf-magma-mgmd-mib-12.txt]


> 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.

Yes, I can read that from yoru DESCRIPTION clause. But other than that, the
MODULE-COMPLIANCE statements result in exactly the same machine-readable
list of objects that must be supported.

>>
>> 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.

So to me, then that means you would replace:

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 }

WIth something like

mgmdHostExtendedMIBGroup OBJECT-GROUP

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

And then of course you would change the name of the GROUP in the
MODULE-COMPLIANCE statements as well.

>>
>> 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.

Kind of strange, but OK, I probably nee to dig in and understand the 
technology
better before I understand that.

>>
>> 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.

OK, I will suggest MODULE-COMPLIANCE statement accordingly

>>
>>
>> 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.

Do you want me to go ahead and make more suggestions on the
MODULE-COMPLIANCE statements, or do you get the gist of what I would
prefer to see?

Bert

>>
>> 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
>
>