Subject: [MIB-DOCTORS] MIB doctor review of draft-ietf-mboned-ip-mcast-mib-05.txt

From: John Flick <[email-masked]>
Date: Tue, 26 Jun 2007 19:42:06 -0700

Hi,

I have completed my review of draft-ietf-forces-mib-04, as
requested by Dan Romascanu.

The following comments are structured according to the MIB
Review Checklist in Appendix A of RFC 4181.

This document was already "pre-reviewed" by Bert Wijnen, so
I have attempted to avoid overlap with his comments.

1. I-D Boilerplate - OK.

2. Abstract - OK.

3. MIB Boilerplate - OK.

4. Security Considerations - Does not follow the approved
boilerplate verbatim, but it does appear complete and
well written, and if anything provides more detail than
the usual boilerplate text.

5. IANA Considerations Section - should probably follow
the template in RFC 4181, section 3.5.2.

6. References:

ID-nits reports the following:

   == Unused Reference: 'RFC2434' is defined on line 2308, but no
      explicit reference was found in the text
      '[RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing
      an...'

   == Unused Reference: 'RFC3306' is defined on line 2331, but no
      explicit reference was found in the text
      '[RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
      Mu...'

   == Unused Reference: 'RFC4007' is defined on line 2343, but no
      explicit reference was found in the text
      '[RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
      and...'

   == Unused Reference: 'RFC4291' is defined on line 2347, but no
      explicit reference was found in the text
      '[RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
      Archi...'

   == Unused Reference: 'I-D.mcwalter-langtag-mib' is defined on line
      2353, but no explicit reference was found in the text
      '[I-D.mcwalter-langtag-mib] McWalter, D., "Language Tag MIB",
      draft-m...'

   == Unused Reference: 'RFC1075' is defined on line 2360, but no
      explicit reference was found in the text
      '[RFC1075]  Waitzman, D., Partridge, C., and S. Deering, "Distance
      Ve...'

   == Unused Reference: 'RFC1584' is defined on line 2364, but no
      explicit reference was found in the text
      '[RFC1584]  Moy, J., "Multicast Extensions to OSPF", RFC 1584,
      March...'

   == Unused Reference: 'RFC2189' is defined on line 2367, but no
      explicit reference was found in the text
      '[RFC2189]  Ballardie, T., "Core Based Trees (CBT version 2)
      Multicas...'

   == Unused Reference: 'RFC2287' is defined on line 2371, but no
      explicit reference was found in the text
      '[RFC2287]  Krupczak, C. and J. Saperia, "Definitions of
      System-Level...'

   == Unused Reference: 'RFC2934' is defined on line 2378, but no
      explicit reference was found in the text
      '[RFC2934]  McCloghrie, K., Farinacci, D., Thaler, D., and B.
      Fenner,...'

   == Unused Reference: 'RFC4601' is defined on line 2389, but no
      explicit reference was found in the text
      '[RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
      "...'

   == Unused Reference: 'I-D.ietf-pim-bidir' is defined on line 2393, but
      no explicit reference was found in the text
      '[I-D.ietf-pim-bidir] Handley, M., Kouvelas, I., Speakman, T., and
      L....'

   == Outdated reference: A later version (-03) exists of
      draft-mcwalter-langtag-mib-02

   -- Possible downref: Normative reference to a draft: ref.
      'I-D.mcwalter-langtag-mib'  (No intended status found in state file
      of draft-mcwalter-langtag-mib)

Many of these are referenced within the MIB module itself, but I think
there typically needs to be a [ref] in the text.  See RFC 4780, section
5.3 for a recent example of one possible way to handle this.

7. Copyright Notices - OK.

8. IPR Notice - OK

9. ID-Checklist issues - OK

10. Technical content

10.1  smilint returns the following warnings:

mibs/IPMCAST-MIB:22: [1] {module-not-found} failed to locate MIB module
  `LANGTAG-TC-MIB'
mibs/IPMCAST-MIB:68: [2] {bad-identifier-case} `XXX' should start with a
  lower case letter
mibs/IPMCAST-MIB:68: [2] {object-identifier-not-prefix} Object
  identifier element `XXX' name only allowed as first element
mibs/IPMCAST-MIB:1479: [2] {basetype-unknown} type `LangTag' of node
  `ipMcastScopeNameLanguage' does not resolve to a known base type
mibs/IPMCAST-MIB:1392: [1] {index-illegal-basetype} illegal base type
  `LangTag' in index element `ipMcastScopeNameLanguage' of row
  ipMcastScopeNameEntry
mibs/IPMCAST-MIB:1410: [2] {type-unknown} unknown type `LangTag'

These all seem okay.

10.2  In the ipMcastInterfaceTable, you define the following counters:
ipMcastInterfaceInMcastOctets, ipMcastInterfaceOutMcastOctets,
ipMcastInterfaceInMcastPkts, ipMcastInterfaceOutMcastPkts.
How do these counters differ from the following counters in the IP-MIB
(RFC 4293): ipIfStatsHCInMcastOctets, ipIfStatsHCOutMcastOctets,
ipIfStatsHCInMcastPkts, ipIfStatsHCOutMcastPkts?

10.3  Typo: ipMcastRouteTimeStamp DESCRIPTION:
s/infomration/information

10.4  It seems that we now have two different ways of configuring
scope zone boundaries for IPv6 multicast: the ipMcastBoundaryTable
in this document and the ipv6ScopeZoneIndexTable in RFC 4293.  How
do we handle cases where these tables are not configured consistently?

10.5  Does the ipMcastLocalListenerTable present essentially the same
information as the mgmdHostCacheTable in the draft-ietf-magma-mgmd-mib?
Do we need both tables?

10.6  The ipMcastLocalListenerTable is not indexed by interface.  Don't
local listeners ordinarily register per-interface?

10.7 ipMcastMIBRouteGroup: with my implementer hat on, I see that
ipMcastRoutePkts, ipMcastRouteTtlDropPackets and
ipMcastRouteDifferentInIfPackets are all required for routers.  I have
worked on multicast routing on a few different ASICs, from a few
different manufacturers, and only one of them would have had the
necessary instrumentation to implement these counters.  Can we
really make them mandatory if there is a lot of silicon out there that
can't support them?

I hope the above comments are helpful.

Thanks,
John

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 27 Jun 2007 07:41:28 +0200

Thanks, John. 

Document shepherd and editors - please address the comments in John's
review. 

I guess that with Bert and John's comments altogether 'Revised ID
needed' is the appropriate state. 

Dan

> -----Original Message-----
> From: John Flick [mailto:[email-masked]] 
> Sent: Wednesday, June 27, 2007 5:42 AM
> To: Romascanu, Dan (Dan); [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: MIB doctor review of draft-ietf-mboned-ip-mcast-mib-05.txt
> 
> Hi,
> 
> This document was already "pre-reviewed" by Bert Wijnen, so I 
> have attempted to avoid overlap with his comments.
> 
> 1. I-D Boilerplate - OK.
> 
> 2. Abstract - OK.
> 
> 3. MIB Boilerplate - OK.
> 
> boilerplate verbatim, but it does appear complete and well 
> written, and if anything provides more detail than the usual 
> boilerplate text.
> 
> 5. IANA Considerations Section - should probably follow the 
> template in RFC 4181, section 3.5.2.
> 
> 6. References:
> 
> Many of these are referenced within the MIB module itself, 
> but I think there typically needs to be a [ref] in the text.  
> See RFC 4780, section
> ipMcastInterfaceInMcastOctets, 
> ipMcastInterfaceOutMcastOctets, ipMcastInterfaceInMcastPkts, 
> ipMcastInterfaceOutMcastPkts.
> How do these counters differ from the following counters in 
> the IP-MIB (RFC 4293): ipIfStatsHCInMcastOctets, 
> ipIfStatsHCOutMcastOctets, ipIfStatsHCInMcastPkts, 
> ipIfStatsHCOutMcastPkts?
> 
> 10.4  It seems that we now have two different ways of 
> configuring scope zone boundaries for IPv6 multicast: the 
> ipMcastBoundaryTable in this document and the 
> ipv6ScopeZoneIndexTable in RFC 4293.  How do we handle cases 
> where these tables are not configured consistently?
> 
> 10.5  Does the ipMcastLocalListenerTable present essentially 
> the same information as the mgmdHostCacheTable in the 
> draft-ietf-magma-mgmd-mib?
> Do we need both tables?
> 
> 10.6  The ipMcastLocalListenerTable is not indexed by 
> interface.  Don't local listeners ordinarily register per-interface?
> 
> 10.7 ipMcastMIBRouteGroup: with my implementer hat on, I see 
> that ipMcastRoutePkts, ipMcastRouteTtlDropPackets and 
> ipMcastRouteDifferentInIfPackets are all required for 
> routers.  I have worked on multicast routing on a few 
> different ASICs, from a few different manufacturers, and only 
> one of them would have had the necessary instrumentation to 
> implement these counters.  Can we really make them mandatory 
> if there is a lot of silicon out there that can't support them?
> 
>