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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 1 Dec 2011 16:08:46 +0100

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?