Subject: mboned: draft-ietf-mboned-ip-mcast-mib-00 review

From: Pekka Savola <[email-masked]>
Date: Tue, 2 May 2006 17:15:07 +0300 (EEST)

Hi,

As I had already lost my MIB review innocence a couple of weeks ago, I 
happened to take a look at the ip mcast mib...

Two higher level comments:

  - multicast scoping seems to call for some kind of MIB object for 
monitoring the number of packets which are dropped at the borders of 
the scope zone because forwarding them would have caused a scope 
violation.  At least if we used scopes ourselves, we'd want to monitor 
that information for non-link-local scopes.

  - as an operator, I greet "ipMcastRouteDifferentInIfPackets" with 
joy.  This is exactly the thing I'd like to monitor (and I hadn't 
known this existed).  Unfortunately, it's not included in the basic 
support but I see it's supported by at least two major vendors. 
Would it be feasible to extend basic support to include this as well 
-- note that if that would make any difference an interface-specific 
counter would be OK as well.

There are probably more like this but I'd guess they're PIM-specific.

(As an aside, as an operator, it would be nicer if all the interfaces would
have 64 bit counters, not just ones faster than 20Mbit/s, but as this comes
from IF-MIB, this isn't an issue specific to this document..)

substantial
-----------

ipMcastRouteNextHopClosestMemberHops OBJECT-TYPE
     SYNTAX     Unsigned32 (0..2147483647)

==> the range should be (0..255) ..

ipMcastScopeNameLanguage OBJECT-TYPE
     SYNTAX     LanguageTag
     MAX-ACCESS not-accessible
     STATUS     current
     DESCRIPTION
             "Language tag associated with the scope name."
     REFERENCE "RFC 1766"

==> rfc 1766 has been obsoleted long time ago by two RFCs; I'm not sure
whether this requires more significant change rather than just updating a
reference pointer..

editorial
---------

  This memo specifies a MIB
    module that is compliant to the SMIv2, which is described in STD 58,
    [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580].

==> this way of referencing STD 58 3 times looks a bit funny.. is there a
better way of doing it?

    This MIB module uses textual conventions defined in the IF-MIB
    [RFC2863], the INET-ADDRESS-MIB [RFC4001] and the IANA-RTPROTO-MIB.

==> reference to IANA-RTPROTO-MIB might be good.

ipMcastBoundaryAddress OBJECT-TYPE
...
     REFERENCE "RFC 2365, RFC 2373"

==> you should update the 2373 reference; it has been updated twice since..
(same in multiple places)

  The support for SET operations in a non-secure
    environment without proper protection can have a negative effect on
    network operations.  These are the tables and objects and their
    sensitivity/vulnerability:

[... then a some other discussion of security stuff..]

==> you should probably change ':' to '.' or do some other rewording as the
list of tables isn't following the sentence..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: "David McWalter" <[email-masked]>
Date: Wed, 3 May 2006 14:03:44 +0100

Hi Pekka.

It's great that you've reviewed the MIB.  Thanks.

I plan to make the following changes.  Let me know if you'd like anything different.

Dave McW.

1)  It would be good to count dropped packets at zone boundaries.
-  In table ipMcastBoundaryEntry, I'll add a packet count and an octet count with text like:
"The number of [octets of] multicast packets that have been dropped as a result of this zone boundary configuration."
-  I'll add these two new counts to conformance group ipMcastMIBBoundaryIfGroup.

2)  ipMcastRouteDifferentInIfPackets is really useful, and should be included in basic support for this MIB.
-  Okay.  Unless anyone objects, I'll move the contents of ipMcastMIBPktsGroup into the more basic group ipMcastMIBRouteGroup, which is mandatory for routers.

3)  ipMcastRouteNextHopClosestMemberHops range should be (0-255)
-  You're right - will fix.

4)  ipMcastScopeNameLanguage references obsolete RFC 1766.
-  Yep, RFC 1766 is obsoleted by BCP RFC 3066 and standards-track RFC 3282.  So I'll update the MIB to reference 3283.  This MIB is agnostic about the languages used for scope names, so I'm treating these language fields as opaque.  So I don't believe any substantial changes are required.  We should provide a pointer to the current syntax though - well spotted.

5)  Multiple references for STD 58.
-  I'll tidy them up.

6)  Reference to IANA-RTPROTO-MIB might be good.
-  Yes.  I mention it in section 4 but there's no formal reference.  I'll add one.

7)  RFC 2373 reference is stale.
-  Yes (2373->3513->4291).  Will fix references.

8)  Wording of security considerations is unclear.
-  Will fix.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Pekka Savola
Sent: 02 May 2006 15:15
To: [email-masked]
Subject: mboned: draft-ietf-mboned-ip-mcast-mib-00 review

Hi,

substantial
-----------

editorial
---------