Subject: [ipcdn] MIB Docotor review of: draft-ietf-ipcdn-igmp-mib-04.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 14 Aug 2002 15:47:20 +0200

First, I am copy-ing Bill and Dave because

- The document is basically about IGMP applicability for DOCSIS
- Bill is main author/editor for IGMPv2 (RFC2236)
- Dave is co-author of IGMP MIB (RFC2933)

It seems that Bill and Dave (or one of the other IGMP MIB authors)
should take a look at this too. 
Or maybe the IDMR WG should look at it.

Comments based on my own quick review:

1. This is mostly about IGMP applicability in DOCSIS environment.
   The applicability/required-conformance is expressed in terms
   of values in MIB objects in the IGMP MIB.
   That is sort of weird. I would rather assume that the MIB 
   (when queried) returns the values as they actually exist.

2. For exmaple (and this is just one example), sect 4.1.1.2
   regarding the igmpInterfaceQueryInterval.

        Passive Mode 
        ------------ 
        HFC-side:  n/a, read-only. The CM MUST not transmit queries 
                   upstream. Return a value of zero. 

   This seems wrong to me. If the object is implemented and accessible,
   then the agent MUST return the proper/actual value.
   I think what you want to say is that the HFC side should NOT/NEVER
   transmit IGMP Host Query packets. if so, then pls say so. It may mean
   that this MIB object therefor will have a value of zero, and that is
   fine. But the requirement (I think) is that the HFC side does not
   transmit packets at any time. 

        CMCI-side: read only . This value is derived based on the interval 
                   of queries received from an upstream querier. 

   This seems wrong too. At least it does not agree with the DESCRIPTION
   clause of the object in the igmp MIB

3. Another example (again an example) is section 4.1.1.1 on
   igmpInterfaceIfIndex:
    
       The ifIndex value of the interface for which IGMP is enabled. 
    
       All Modes / Both sides: same for passive and active modes. 
    
       HFC-side:  not-accessible. ifIndex of docsCableMaclayer(127), CATV 
                  MAC Layer 
       CMCI-side: not-accessible. ifIndex of CMCI-Side interface.

   These objects are INDEX objects (and as you say not accessible).
   So if anything, then maybe what you are saying is that the MIB
   should only contain instances (rows/entries) for interfaces that
   are of ifType 127 on the HFC side. Not sure I understand what you
   are saying for CMCI side (actually I am sure I do not understand).

4. Yet another example:
      4.1.1.3   igmpInterfaceStatus 
    
      The activation of a row enables IGMP on the interface. The 
      destruction of a row disables IGMP on the interface. 
    
   Sofar it is a repeat of what IGMP MIB already says. Seems useless.

      All Modes / Both sides: MUST be enabled on both interfaces for all 
      DOCSIS 1.1 CM interfaces. 

   Well, the value for the object then is 'active'.
   But I think what you are basically saying is that Bother sides MUST
   support IGMP on all their CM interfaces. 
   Again, the instance of the MIB on a device should just relfect the
   actual situation, no matter if that is compliant with your 
   spec or not.

5. As a last example:
       4.1.1.4   igmpInterfaceVersion 
    
       The version of IGMP which is running on this interface. 
   
       All Modes / Both sides: MUST be version 2 for all DOCSIS 1.1
       CM interfaces. 
 
   I think what you are saying that DOCSIS devices MUST implement IGMPv2
   for all of their CM interfaces.

   Again, the MIB, when queried MUST report the actual situation.

It seems to me, before we go into more detail on these sort of things that
we need to agree on how to specify your IGMP requirements for DOCSIS
devices. But it seems to me that it is not appropriate to do so in
the form of expected MIB object values.

Additional comments:

6. sect 4.3.1.2 and sect 4.3.2.3 seem duplicates?

7. sect 4.3.2.5 and sect 4.3.2.6 seem not to be represented in the
   compliance statements in sect 4.3.1

8. When we get to section 4.3, maybe what you are trying to do is to
   tell DOCSIS device manufacturers that they do not have to implement
   the complete IGMP MIB on all devices. So what you may want to do
   is to specify special compliance statements. That seems a good idea.
   
   To do so, you should enclose them in a real MIB-MODULE (it can
   just contain the complaince statements). It would look aka:

      DOCS-IGMP-MIB-COMPLIANCES DEFINITIONS BEGIN
  
      IMPORT ...

      docsIgmpMibCompliancesMIB MODULE-IDENTITY
      ....
   
      docsIgmpV2PassiveDeviceCompliance MODULE-COMPLIANCE 
        STATUS current 
        DESCRIPTION 
        "The compliance statement for DOCSIS Devices passively running 
         IGMPv2 and implementing the IGMP MIB." 
        MODULE IGMP-STD-MIB 
        MANDATORY-GROUPS { igmpBaseMIBGroup, 
                           igmpRouterMIBGroup, 
                           igmpV2RouterMIBGroup 
                         } 
        OBJECT igmpInterfaceStatus 
        SYNTAX       RowStatus { active(1) }
        MIN-ACCESS   read-only
        DESCRIPTION
            "Write access is not required, and active is the only
             status that needs to be supported."

        OBJECT igmpCacheStatus 
        MIN-ACCESS read-only 
        DESCRIPTION 
        "Write access is not required." 
        ::= {docsIgmpMIBCompliances 1} 
   
      ...

      END

   Note that the way I specify read-only for igmpInterfaceStatus is
   also different from what you had done. I think my way is the correct
   (or at least better) way. I know that the IGMP MIB has it the same
   as you have. In fact you have exactly the same compliance statement.
   If that is what you want, then you just tell people that they must
   implement igmpV2RouterMIBCompliance.

9. An additional comment is, that if you allow igmpInterfaceStatus
   to be read-only, then I think you have to allow all objects
   in that table to be read-only, or maybe read-write. If you do
   not allow read-create access to a RowStatus object, then new rows
   cannot be created, and so none of the objects should then allow
   read-create access.

10. This applies equally well to the igmpCacheStatus object/rows of
    course.

11. If you allow for some people to do a read-write and others to
    do a read-only implementation, then I prefer to see 2 
    compliance statements. The Diffserv MIB (RFC3289) is a good
    example on how to do it. so you would have a

    xxxxMIBFullCompliance that does NOT allow for read-only
    xxxxMIBReadOnlyCompliance that does allow for the read-only
                              implementations
12. You are also proposing a new object in the docsis device MIB.
    I do not understand why you do that, you have a revision of that
    MIB being worked on in the WG, so you can just refer to that
    new MIB and talk about the new object that you need.

13. And it then seems to me that you want to include that object in
    the COMPLIANCE statements that we talked about above. So you
    import a new group from the docsis device MIB and include it in
    the compliance statement(s) above.

14. By the way, you cannot add objects to an existing group. That
    could break the compliance that some people have claimed already.
    So you must define a new group, aka docsdevbaseGroup2. It could
    either just contain that one new objects, or it could contain 
    the old list of objects plus the new object.

Additional non-technical comments:

15. Acronyms used in Title and Abstract
16. References not split in normative/informative
17. references used in abstract section
18. a lot of RFC2119 language used while this is informational.

for the first 15/16/17, see: http://www.rfc-editor.org/policy.html

Bert 
AD for Network Management side of OPS Area

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Dave Thaler" <[email-masked]>
Date: Fri, 23 Aug 2002 19:33:21 -0700

> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
[...]
> Or maybe the IDMR WG should look at it.

Section 3 really duplicates part of the "IGMP Proxy" spec 
(expired?) by Bill.

The model appears to be that a CM is a typical IGMP Proxy.
On such a device, the objects covered by igmpV2HostMIBCompliance
Should apply on the HFC-side and the objects covered by 
igmpV2RouterMIBCompliance should apply on the CMCI-side if 
in active mode. In passive mode CMCI-side, a subset will apply 
which is not covered by any existing compliance statement in
the IGMP MIB.

4.1.1.2   igmpInterfaceQueryInterval 
>               upstream. Return a value of zero.
Since the HFC-side is in host-mode not router mode, there should
be no instance of this object on the HFC-side.  It should not
return 0.  Same for igmpInterfaceQueryMaxResponseTime,
igmpInterfaceQuerierExpiryTime, igmpInterfaceJoins, etc.

4.1.1.5   igmpInterfaceQuerier
>   HFC-side:  read-only. MUST be the address of an upstream device for 
>               both active and passive CMs.
This equates to saying the optional igmpHostOptMIBGroup group
is actually mandatory in this spec.

4.1.1.8   igmpInterfaceQuerierExpiryTime
>   Both Sides: n/a, read-only. The CM is never the querier, return 0.
This is definitely wrong.  The DESCRIPTION of this object says:
            "The amount of time remaining before the Other Querier
            Present Timer expires.  If the local system is the querier,
            the value of this object is zero."
The value should only be present and 0 when one is the querier.
If you can never be the querier, then you're not in router-mode, and
hence
no object instance should be present.

4.1.1.10  igmpInterfaceWrongVersionQueries
>   All Modes / Both sides - read-only. The number of non-v2 queries 
>   received on this interface.
As with igmpInterfaceQueryInterval, I see no reason for this object to
be present on the HFC-side.

--- stopped here for the moment, but you can probably extrapolate what
my responses to a bunch of other objects will be when I get a few more
minutes.

-Dave

---

From: "Dave Thaler" <[email-masked]>
Date: Fri, 23 Aug 2002 19:33:21 -0700

[...]

-Dave