Subject: [MIB-DOCTORS] Second Call for volunteers for http://www.ietf.org/internet-drafts/draft-ietf-mboned-ip-mcast-mib-05.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 7 Jun 2007 07:17:37 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 7 Jun 2007 17:40:38 +0200

Dan, I did a very very quick check and have some concerns that I
can write down. But I did not do a full MIB doctor review, and I
am not sure I can get to such a full MIB Doctor Review before I leave
for vacation on June 15th. So how do you want me to send my comments?

Bert Wijnen  

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Thursday, June 07, 2007 7:18 AM
> To: [email-masked]
> Cc: [email-masked]
> 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!
> 
> 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.
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 7 Jun 2007 17:43:05 +0200

Yes, please do. I will complete the rest of the review myself, unless
somebody else jumps to my help :-)

Dan

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Thursday, June 07, 2007 6:41 PM
> To: Romascanu, Dan (Dan)
> Cc: MIB Doctors (E-mail)
> Subject: RE: [MIB-DOCTORS] Second Call for volunteers 
> Dan, I did a very very quick check and have some concerns 
> that I can write down. But I did not do a full MIB doctor 
> review, and I am not sure I can get to such a full MIB Doctor 
> Review before I leave for vacation on June 15th. So how do 
> you want me to send my comments?
> 
> Bert Wijnen  
>

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 7 Jun 2007 23:45:58 +0200

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

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 12 Jun 2007 10:34:36 +0200

Thanks for the updates and the chance to pre-review.

comments inline

Bert Wijnen  

> From: David McWalter [mailto:[email-masked]] 
> Sent: Monday, June 11, 2007 5:26 PM
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Romascanu, Dan (Dan)
> Subject: RE: Half-MIB-Doctor review for 
> http://www.ietf.org/internet-drafts/draft-ietf-mboned-ip-mcast
> -mib-05.txt
> 
> Bert,
> 
> I appreciate this review, thank-you.  I've numbered your 
> points for reference, with proposed resolutions and questions below.
> 
> I'll hold off submitting -06 for a few days in case anyone 
> would like to comment on these resolutions.
> 
> Best regards, and enjoy your vacation.
> David McWalter.
> 
> 
> (1) That sub-ID structure was copied from RFC 2932.  Will 
> remove in -06.
> (2) Okay; ipMcastEnable -> ipMcastEnabled TruthValue in -06.
> (3) Added ipMcastDeviceStorageType, 
> ipMcastInterfaceStorageType, covers the three read-write 
> fields.  Text copied from PIM-MIB.

OK. Using storageType for a scalar is somewhat heavy. But acceptable.

> (4) Allowing 256 would add a behavior (i.e. don't forward any 
> packets at all).  No harm in that, so will add in -06.  Will 
> also change ipMcastRouteNextHopClosestMemberHops to keep the 
> objects consistent.
> (5) We thought about that for PIM-MIB too.  I plan to add 
> some text to the compliance statements in -06, but leave the 
> syntax alone.

I personally am not happy with "conflicting syntax" in a set of
InetAddresType/InetAddress definitions. I think that it is an
error. I know that in practice it may not hurt too badly, but
it is just impossible to use some of the valid InetAddressTypes
given the restrictions you have put on the size for InetAddresses.

I would think that most (if not all) MIB doctors agree with me.
But, they can speak up if not. I avebcc:-ed the MIB doctors list.

> (6) You're right.  I'll change the reference to RFCzzzz, and 
> also change the note to the editor.
> (7) Let's drop the IMPLIED.  I see no problem with adding a 
> length to the OID to keep SMICng happy.

Note that it is not just "to make SMICng happpy". It is a fact that
for a possible size of zero, the IMPLIED is not acceptable.

> (8) Will add 'Obsoletes: RFC 2932 (when approved)' in -06.
> (9) Sure, I'll add that to REVISION DESCRIPTION in -06.  I 
> guess the duplicate text should stay in sect 2.

I think that is indeed OK

> (10) Oops.  Will fix IF-MIB references in -06 (there are several).
> (11) Will change title of 6.1 from 'SNMPv2' to 'SNMPv3'.
> 
> (Diff for these proposed updates is attached.)
> 

Bert
> Sent: 07 June 2007 22:46
> To: [email-masked]; [email-masked]; David McWalter
> Cc: [email-masked]; Romascanu, Dan (Dan)
> Subject: Half-MIB-Doctor review for
> t
> after my vacation (that would be after July 8th, and after a 
> vacation, there is always a bulk load of work waiting for me...)
> 
> (1) I wonder about this:
> (2) ipMcastEnable OBJECT-TYPE
>   I wonder if it would not be better renamed to 
> ipMcastEnabled and then use
> (3) I am missing any text w.r.t. the expected persistency 
> behaviour of various
> (4) I see:
> (5) I see various 
> (6) I guess the LANGTAG-TC-MIB is in 
> 
>   maybe somewhat confusing, because you also use yyyy for 
> your own RFC as per
> 
> (7) SMICng tells me:
> (8) Top of title page should have a line
> 
> (9) You might consider to icnlude most of the history of sect 2 in the
> (10) I see (at the end of sect 4):
> 
> (11) Security Considerations.