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

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

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

comments inline

Bert Wijnen  

> -----Original Message-----
> From: David McWalter [mailto:[e-mail]] 
> Sent: Monday, June 11, 2007 5:26 PM
> To: Wijnen, Bert (Bert)
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; 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
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[e-mail]]
> Sent: 07 June 2007 22:46
> To: [e-mail]; [e-mail]; David McWalter
> Cc: [e-mail]; Romascanu, Dan (Dan)
> Subject: Half-MIB-Doctor review for
> http://www.ietf.org/internet-drafts/draft-ietf-mboned-ip-mcast
> -mib-05.tx
> t
> 
> 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.
> 
> (1) I wonder about this:
> 
>       ipMcastMIBObjects OBJECT IDENTIFIER ::= { ipMcastMIB 1 }
> 
>       ipMcast      OBJECT IDENTIFIER ::= { ipMcastMIBObjects 1 }
> 
>    Why do you introduce that extra SUB-ID ??
> 
> (2) 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.
> 
> (3) I am missing any text w.r.t. the expected persistency 
> behaviour of various
>   writable (read-write) objects.
> 
> (4) 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" ?
> 
> (5) 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.
> 
> (6) 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."
> 
> (7) 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:
> 
> (8) Top of title page should have a line
> 
>   Obsoltes: RFC2932 (when approved)
> 
> (9) 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.
> 
> (10) 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.
> 
> (11) 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