Re: [Fwd: Additional comments on draft-ietf-magma-mgmd-mib-12.txt]
"Bert Wijnen \(IETF\)" <[email protected]> Fri, 3 Oct 2008 16:57:10 +0200
| Newsgroups | gmane.ietf.magma |
|---|---|
| Organization | Consultant |
| Message-ID | <6B3B45CE1A0D4971B0AB226CDB07C046@BertLaptop> |
bcc: to mib-doctors
I see in yoru MIB module
mgmdIgmpV1RouterReadMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"A read-only compliance statement for routers running
IGMPv1 [RFC 1112] and implementing the MGMD MIB. IGMPv1
routers must support the IPv4 address type "
MODULE -- this module
GROUP mgmdRouterReadBaseMIBGroup
DESCRIPTION
"Read-only access required."
::= { mgmdMIBCompliance 2 }
So NO MANDATORY group at all.
So theorethically, one can implement nothing and still be compliant?
Did you mean:
mgmdIgmpV1RouterReadMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"A read-only compliance statement for routers running
IGMPv1 [RFC 1112] and implementing the MGMD MIB. IGMPv1
routers must support the IPv4 address type "
MODULE -- this module
MANDATORY-GROUPS { mgmdRouterReadBaseMIBGroup }
DESCRIPTION
"Read-only access required."
::= { mgmdMIBCompliance 2 }
instead? I.e. that that one group MUST be implemented, but that
read-only implemebntation is fine?
Bert
----- 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.
>>
>> 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
>
>