Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss on draft-ietf-trill-rbridge-mib-04: (withDISCUSS and COMMENT)

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Jan 2012 08:02:59 -0500

MIB Doctors - I don't think I've seen a reply to Dan's request for a formal MIB Doctor review of draft-ietf-trill-rbridge-mib-04.  The lack of a MIB Doctor review is blocking progress on this document, so I would greatly appreciate one of you volunteering to review the document.

- Ralph

On Dec 1, 2011, at 10:08 AM 12/1/11, Romascanu, Dan (Dan) wrote:

> MIB Doctors,
> 
> Please see the DISCUSS entered by Adrian. Both Bert and me provided comments on the earlier versions of the MIB module but did not have time for a full MIB review. I sent a formal call for volunteers to this list when the document was sent to IETF LC (on 10/30), but this one was not answered. Sure the IETF meeting interfered, but right now the lack of a MIB doctors review blocks the document, and the there seem to be some problems (or at least questions) raised by Adrian. 
> 
> Please jump in to help. 
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Thursday, December 01, 2011 4:59 PM
> To: The IESG
> Cc: [email-masked]; [email-masked]
> Subject: Adrian Farrel's Discuss on draft-ietf-trill-rbridge-mib-04: (withDISCUSS and COMMENT)
> 
> Adrian Farrel has entered the following ballot position for
> draft-ietf-trill-rbridge-mib-04: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Has a MIB doctor review been done yet? It seems like one is still
> needed. I am not a MIB expert, but I think I see a number of issues.
> 
> ---
> 
> I'm afraid Sean's Comment needs to be captured in a Discuss. 
> 
> Please resolve the downref to RFC 4663 either by moving it to 
> Informative (which seems reasonable) or by reissuing the last call.
> 
> ---
> 
> I would like help from the OPS ADs (and MIB Doctors) on this point:
> 
> It seems to me that section 6.7 needs a new conformance statement to
> be applied to ISIS-MIB. The text in the sectionappears to be in two 
> parts:
> 
> - Implementation guidance (what value to return on a GET from a Trill
>  implementation)
> 
> - Implementation requirements (which tables/objects to implement or not
>  (conformance statement).
> 
> ---
> 
>   RbridgeNickname ::= TEXTUAL-CONVENTION
>       DISPLAY-HINT "d"
>       STATUS current
>       DESCRIPTION
>           "The 16-bit identifier used in TRILL as an
>           abbreviation for the RBridge's 48-bit IS-IS System ID.
>           The value 0 means a nickname is not specified, the values
>           0xffco through 0xfffe are reserved for future allocation,
>           and the value 0xffff is permanently reserved."
>   SYNTAX Unsigned32 (0..65471)
> 
> As specified, if the reserved values are ever allocated for any reason
> you will have to respin the MIB module. You probably don't want to have
> to do that, so why not allow 0..65534? (By the way, if 0xffff is outside
> the available range, it is by definition permanetly reserved, so maybe 
> you don't need to say anytng about it.)
> 
> ---
> 
> There seems to be some confusion about defaults.
> 
> There are a number of cases where the DESCRIPTION clause states a
> specific value for the default of a read-write or a read-create object.
> For example:
> 
>   rbridgeBaseForwardDelay OBJECT-TYPE
>       SYNTAX      Unsigned32
>       UNITS       "seconds"
>       MAX-ACCESS  read-write
>       STATUS      current
>       DESCRIPTION
>           "Modified aging time for address entries after an appointed
>           forwarder change. The default value is 15.
> 
>           The value of this object MUST be retained across
>           reinitializations of the management system."
>       REFERENCE
>            "RBridge section 4.8.2"
>      ::= { rbridgeBase 3 }
> 
> This appears to be missing a DEFVAL clause unless you mean something
> different by "default". If you actually mean that the default in an
> implementation of the protocol is 15, then it is not appropriate to
> mention it here.
> 
> In other objects (rbridgeBaseUniMultipathEnable,                      
> rbridgeBaseMultiMultipathEnable) you have "The default is
> implementation-specific." If this applies to the implementation of the  
> management agent then you might guide the implementer. If it applies to
> the implementation of the protocol, then it doesn't really belong here.
> 
> I suggest you look at each DESCRIPTION clause where there is a default
> described and work out whether you should:
> - add a DEFVAL clause
> - reomove the txt
> - extend the text to give additional advice to the implementer of the
>  management agent.
> 
> (By the way, sometimes you have included the DEFVAL just fine.)
> 
> ---
> 
>   rbridgeBasePortIfIndex OBJECT-TYPE
>       SYNTAX      InterfaceIndex
> 
> Should this be InterfaceIndexOrZero? What would happen if the entry was
> deleted from IF-MIB?
> 
> ---
> 
> I expected to see some mention of rbridgeSnoopingAddrType in the
> conformance statement to limit its applicability to only a few of the
> address types.
> 
> ---
> 
>   rbridgeDtreeActiveTrees OBJECT-TYPE
>       SYNTAX      Unsigned32
> 
> Shouldn't this more properly be a Gauge32?
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> You should mainly be saying "MIB module" where you say "MIB"
> 
> ---
> 
> Some of the IMPORTS clause entries usefully point to the RFCs housing
> the imported TCs. It would be great if you could include the references
> for all the others.
> 
> ---
> 
> I appreciate the many REFERENCE clauses. Could add one to 
> RbridgeNickname.
> 
> ---
> 
>   -- Implementation of the rbridgeBase subtree is mandatory for all
>   -- RBridges.
> 
> Does this mean
> ... that are conformant to this MIB module
> Or are you making a wider statement about Rbridges?
> 
> ---
> 
> The DESCRIPTION clause of rbridgeSnoopingPortAddr should indicate the
> (obvious) fact that the object is interpretted in the context of 
> rbridgeSnoopingPortAddrType.
> 
> ---
> 
>   rbridgeDtreeActiveTrees OBJECT-TYPE
>       SYNTAX      Unsigned32
>       MAX-ACCESS  read-only
>       STATUS      current
>       DESCRIPTION
>           "The total number of trees being computed by all Rbridges
>           campus."
> 
> Missing some text in the DESCRIPTION clause?
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 24 Jan 2012 14:17:51 +0100

MIB Doctors,

Please step ahead to help with reviewing this document. If I understand
well its progress depends now on its MIB review! Note that Bert and me
have already reviewed previous versions, and that O have already entered
a DISCUSS on this version related to rbridgeBaseNicknameTable and
rbridgeEsadiTable including read-create objects but now RowStatus
objects. However, a complete MIB Doctor review is necessary. 

Thanks and Regards,

Dan

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Tuesday, January 24, 2012 3:03 PM
> To: [email-masked]
> Cc: Adrian Farrel; Romascanu, Dan (Dan)
> Subject: Re: Adrian Farrel's Discuss on draft-ietf-trill-rbridge-mib-
> 04: (withDISCUSS and COMMENT)
> 
> MIB Doctors - I don't think I've seen a reply to Dan's request for a
> formal MIB Doctor review of draft-ietf-trill-rbridge-mib-04.  The lack
> of a MIB Doctor review is blocking progress on this document, so I
> would greatly appreciate one of you volunteering to review the
> document.
> 
> - Ralph
> 
> > Please see the DISCUSS entered by Adrian. Both Bert and me provided
> comments on the earlier versions of the MIB module but did not have
> time for a full MIB review. I sent a formal call for volunteers to
this
> list when the document was sent to IETF LC (on 10/30), but this one
was
> not answered. Sure the IETF meeting interfered, but right now the lack
> of a MIB doctors review blocks the document, and the there seem to be
> some problems (or at least questions) raised by Adrian.
> >
> > Please jump in to help.
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >
> >
> >
---------------------------------------------------------------------
> -
---------------------------------------------------------------------
> -
---------------------------------------------------------------------
> -
---------------------------------------------------------------------
> -

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Jan 2012 16:43:11 +0100

This is great, please go ahead, thanks Joan!

Regards,

Dan

> From: Joan Cucchiara [mailto:[email-masked]]
> Sent: Thursday, January 26, 2012 5:18 PM
> To: Romascanu, Dan (Dan)
> Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss ondraft-ietf-trill-
> rbridge-mib-04: (withDISCUSS and COMMENT)
> 
> Dan,
> 
> If you haven't had any volunteers yet, then I'm happy to do a review,
> although this
> isn't my area, but I can do it from a MIB perspective.
> 
> Let me know.  (Oh timeframe would be about Feb 7th or so, possibly
> earlier).
> 
> Thanks,
>   -Joan
> 
> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Ralph Droms" <[email-masked]>; <[email-masked]>
> Cc: "Adrian Farrel" <[email-masked]>
> Sent: Tuesday, January 24, 2012 8:17 AM
> Subject: Re: [MIB-DOCTORS] Adrian Farrel's Discuss
> ondraft-ietf-trill-rbridge-mib-04: (withDISCUSS and COMMENT)
> 
> 
> > MIB Doctors,
> >
> >> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of Adrian Farrel
> >> > Subject: Adrian Farrel's Discuss on draft-ietf-trill-rbridge-mib-
> 04:
> >> > email addresses included in the To and CC lines. (Feel free to
cut
> >> > - Implementation requirements (which tables/objects to implement
> or
> >> not
> >> >  (conformance statement).
> >> >
> >> > ---
> >> >
> >> > you will have to respin the MIB module. You probably don't want
to
> >> have
> >> > implementation-specific." If this applies to the implementation
of
> >> the
> >> > management agent then you might guide the implementer. If it
> applies
> >> to
> >> > Should this be InterfaceIndexOrZero? What would happen if the
> entry
> >> was
> >> > deleted from IF-MIB?
> >> >
> >> > ---
> >> >
> > _______________________________________________
> > MIB-DOCTORS mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mib-doctors