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

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Fri, 3 Oct 2008 17:39:21 +0200

I had already suggested to change

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 }

into:

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. In the index, this means
            for object mgmdHostInterfaceQuerierType

              OBJECT     mgmdHostInterfaceQuerierType
              SYNTAX     InetAddressType {ipv4(1)}
              MIN-ACCESS read-only
            "
    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 the only value that needs to be supported is
                 'active'"
    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 }

I see that I shoudl have said:

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. In the index, this means
            for object mgmdHostInterfaceQuerierType

              OBJECT     mgmdHostInterfaceQuerierType
              SYNTAX     InetAddressType {ipv4(1)}
            "
  ....

That object is an INDEX object (that is why I need to describe it in the 
DESCRIPTION
clause, and so MIN-ACCESS read-only is not relevant. In fact it is incorrect 
for an INDEX
object that has a MAX-ACCESS of not-accesible.
The remainder of my suggested text stays the same.

Bert

----- Original Message ----- 
From: "Julian Chesterfield" <[email-masked]>
To: <[email-masked]>
Cc: "Brian Haberman" <[email-masked]>; <[email-masked]>
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
>
> 

_______________________________________________
magma mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/magma

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Fri, 3 Oct 2008 16:57:10 +0200

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

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Fri, 3 Oct 2008 17:52:08 +0200

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-masked]>
To: <[email-masked]>
Cc: "Brian Haberman" <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 23, 2008 12:20 PM
Subject: Re: [Fwd: Additional comments on draft-ietf-magma-mgmd-mib-12.txt]

> The difference is the relevance to hosts utilising the IGMP vs MLD 

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.

>> I personally would even prefer the "Opt" is not part of the name of the

So to me, then that means you would replace:

              mgmdHostInterfaceQuerier, mgmdInverseHostCacheAddress }

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.

>> rowstatus object and none of the otehr objects in the table?

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

> It means that either may be supported, but at least IPv6 must be 

OK, I will suggest MODULE-COMPLIANCE statement accordingly

> 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

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Fri, 3 Oct 2008 18:07:39 +0200

When trying to understand the MODULE-COMPLIANCES a bit better I
had to take a closer look at the OBJECT-GROUPS as well.

And I must say I find it very weird to see a table mgmdHostInterfaceTable
that has this sequence of objects:

  MgmdHostInterfaceEntry ::= SEQUENCE {
  *  mgmdHostInterfaceIfIndex               InterfaceIndex,
  *  mgmdHostInterfaceQuerierType           InetAddressType,
      mgmdHostInterfaceQuerier               InetAddress,
      mgmdHostInterfaceStatus                RowStatus,
      mgmdHostInterfaceVersion               Unsigned32,
      mgmdHostInterfaceVersion1QuerierTimer  TimeTicks,
      mgmdHostInterfaceVersion2QuerierTimer  TimeTicks,
      mgmdHostInterfaceVersion3Robustness    Unsigned32
  }

Those with an * in front of them are the INDEX objects.

I then see OBJECT-GROUPS that have one or more objects from this table
as follows:

mgmdV2IgmpHostWriteMIBGroup OBJECT-GROUP
    OBJECTS { mgmdHostInterfaceVersion
            }
    STATUS  current
    DESCRIPTION
            "A collection of additional read-create objects for
            management of IGMP version 2 in hosts for MGMD version
            2 compliance."
    ::= { mgmdMIBGroups 4 }

mgmdV2IgmpHostReadMIBGroup OBJECT-GROUP
    OBJECTS { mgmdHostInterfaceVersion1QuerierTimer
            }
    STATUS  current
    DESCRIPTION
            "A collection of additional read-only objects for
            management of IGMP version 2 in hosts for MGMD version
            2 compliance."
    ::= { mgmdMIBGroups 5 }

mgmdV3HostWriteMIBGroup OBJECT-GROUP
    OBJECTS { mgmdHostInterfaceVersion3Robustness }
    STATUS  current
    DESCRIPTION
            "A collection of additional read-create objects for
            management of MGMD version 3 in hosts."
    ::= { mgmdMIBGroups 12 }

mgmdV3HostReadMIBGroup OBJECT-GROUP
    OBJECTS { mgmdHostInterfaceVersion2QuerierTimer,

              mgmdHostCacheSourceFilterMode,
              mgmdHostInterfaceVersion3Robustness,
              mgmdHostSrcListExpire
            }
    STATUS  current
    DESCRIPTION
            "A collection of additional read-only objects for
            management of MGMD version 3 in hosts."
    ::= { mgmdMIBGroups 13 }

WHat seems so weird to me is the fact that all these objects are located in 
one
single table (so they seem to belong together) and yet they pop up in many 
differnt
OBJECT groupings as if they have nothing to do with each other. I wonder 
what the
explanation is for this.

I have already mentioned in an earlier email that you SHOULD NOT name
groups xxxReadXxxGroup or xxxWirtexxxGroup or xxxOptxxxGroup nor should
you speak about read-only or read-write or optional objects in the 
DESCRIPTION
clauses of OBJECT-GROUPS. if the objext are read or write, that is something
defined in the MAX-ACCESS clause on the OBJECT-TYPE and in the
MIN-ACCESS clause in the OBJECT clause of a MODULE-COMPLIANCE.
Same for the fact that objects are optional or not. That is done through
the MODULE-COMPLIANCE< not through OBJECT-GORUPing.

Bert Wijnen