[MIB-DOCTORS] Half-MIB-Doctor review for http://www.ietf.org/internet-drafts/draft-ietf-mboned-ip-mcast-mib-05.txt

["Wijnen, Bert \(Bert\)" <[e-mail]>]

Sorry, I do not have time for a full MIB doctor review until
after my vacation (that would be after July 8th, and after a vacation,
there is always a bulk load of work waiting for me...)

But here is what I found after a quick scan through the document.

- I wonder about this:

      ipMcastMIBObjects OBJECT IDENTIFIER ::= { ipMcastMIB 1 }

      ipMcast      OBJECT IDENTIFIER ::= { ipMcastMIBObjects 1 }

   Why do you introduce that extra SUB-ID ??

- ipMcastEnable OBJECT-TYPE
    SYNTAX     INTEGER { enabled(1), disabled(2) }
    MAX-ACCESS read-write
    STATUS     current
    DESCRIPTION
            "The enabled status of IP Multicast function on this
            system."
    ::= { ipMcast 1 }

  I wonder if it would not be better renamed to ipMcastEnabled and then
use
  a TruthValue as the SYNTAX. I like re-use of TCs.

- I am missing any text w.r.t. the expected persistency behaviour of
various
  writable (read-write) objects.

- I see:
  ipMcastInterfaceTtl OBJECT-TYPE
    SYNTAX     Unsigned32 (0..255)
    MAX-ACCESS read-write
    STATUS     current
    DESCRIPTION
            "The datagram TTL threshold for the interface.  Any IP
            multicast datagrams with a TTL (IPv4) or Hop Limit (IPv6)
            less than this threshold will not be forwarded out the
            interface.  The default value of 0 means all multicast
            packets are forwarded out the interface."
    DEFVAL     { 0 }
    ::= { ipMcastInterfaceEntry 3 }

  So what if the TTL or HopLimit is 255? It can never be lesss than
  the value in this object. SO did you mean Unsigned (0..256) maybe?
  Or maybe you meant "less than or equal to this threshold" ?

- I see various 

         SYNTAX     InetAddress (SIZE (4|8|16|20))

  While the corresponding addresstype is

         SYNTAX     InetAddressType

  That seems to conflict to me. for example, a "unknown" or "dns"
  is certainly not valid with thise address size limitations.

  In other places you have

        SYNTAX     InetAddress (SIZE (0|4|8|16|20))


  and so here the the addresstype can include "unknown", but not "dns"

  So maybe you want to be consistent and specify the valid ranges for
  InetAddressType as well.

  Once could wonder if it is wise to limit the ranges here in the SYNTAX
  cluases of the OBJECT-TYPE or if it would be better to specify the
  (current) limitations in the MODULE-COMPLIANCE.

- I guess the LANGTAG-TC-MIB is in 

   [I-D.mcwalter-langtag-mib]
              McWalter, D., "Language Tag MIB",
              draft-mcwalter-langtag-mib-02 (work in progress), I-D
              Status active, March 2007.

  The line 

    LangTag                         FROM LANGTAG-TC-MIB;    -- [RFCyyyy]

  maybe somewhat confusing, because you also use yyyy for your own RFC
as per

    REVISION     "200703010000Z" -- 1 March 2007
    DESCRIPTION  "Initial version, published as RFC yyyy."

- SMICng tells me:
 
    E: f(mcast.mi2), (1342,26) IMPLIED is not compatible for index item
       "ipMcastScopeNameLanguage", since it may have a size of zero

Maybe you need to look at this?

Textual/admin nits:

- Top of title page should have a line

  Obsoltes: RFC2932 (when approved)

- You might consider to icnlude most of the history of sect 2 in the
  DESCRIPTION clause of the MODULE-IDENTITY or of the REVISION clause.

- I see (at the end of sect 4):

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

  Mmm... I am pretty sure that the IF-MIB is in RFC2863, not 4293.

- Security Considerations.
  Is different from the guideline/template at 
  http://www.ops.ietf.org/mib-security.html

  I will leave it to the AD if he finds this acceptable.
  It seemsyou have the basic ingredients present.

  But I am certainly surprised to see the title of section 6.2
          
         6.1  SNMPv2

  What is specific for SNMPv2 ???




Bert Wijnen  

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[e-mail]] 
> Sent: Thursday, June 07, 2007 7:18 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [MIB-DOCTORS] Second Call for volunteers 
> forhttp://www.ietf.org/internet-drafts/draft-ietf-mboned-ip-mc
> ast-mib-05.txt
> 
> 
> This is a second call!
> 
> We need a volunteer to review the revised IP Multicast MIB - 
> http://www.ietf.org/internet-drafts/draft-ietf-mboned-ip-mcast
> -mib-05.tx
> t. 
> 
> The document is co-authored by Dave Thaler and seems to be in 
> pretty good shape, yet an independent MIB Doctor review would 
> be even better.
> 
> Please step ahead for the task. 
> 
> Thanks and Regards,
> 
> Dan
> 
>  
> 
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mib-doctors
> 


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