Subject: Re: [MIB-DOCTORS] [rbridge] Volunteer needed to reviewdraft-ietf-trill-rbridge-mib-03

From: Ralph Droms <[email-masked]>
Date: Thu, 1 Sep 2011 11:47:24 -0700

Dan - thanks for your review and comments.

I will ask the authors to produce a revised document, which can then be given a MIB Doctor review.

- Ralph

On Aug 18, 2011, at 6:40 AM 8/18/11, Romascanu, Dan (Dan) wrote:

> Hi,
> 
> We did not receive any volunteering offers. The list is still open and
> the MIB doctors are invited to step ahead. 
> 
> Bert and me did however a quick review of the I-D. Here are our
> findings. Please treat them as review comments, but keep in mind that
> the list is not final and more things may accumulate. 
> 
> I would also note that I reviewed a previous version of the MIB module
> and document and made a number of comments. Not all were taken into
> consideration. 
> 
> 1. The relationship with other MIB module sections refer to the IETF
> RFCs. However, since 2006 the development of the Bridge MIB modules and
> their successors were transferred to IEEE 802.1. I suggest to define the
> relationship sections in relation to the IEEE MIB modules
> 
> 2. There are several tables with read-create objects but no rowStatus
> object - rbridgeBaseNicknameTable, rbridgeBasePortTable,
> rbridgeVlanPortTable, etc.
> 
> 3. There are several writeable objects and tables with writeable objects
> but no rowStorageType or any indication about persistency
> 
> 4. In several places SYNTAX of Integer32 is used for range positive
> integers. RFC 4181, section 4.6.1.1 says: 
> 
> - If the value range is between 0..4294967295 (inclusive), and values
>     greater than 2147483647 are possible, and the value of the
>     information being modelled does not increase above the maximum
>     value nor decrease below the minimum value, then:
> 
>     - Unsigned32 is RECOMMENDED;
>     - Gauge32 is acceptable;
>     - INTEGER and Integer32 MUST NOT be used.
> 
> 5. Use of Inter32 (0-65535) for port numbers instead of using
> InetPortNumber from RFC4001
> 
> 6. SMICng strict checking gives:
> 
> W: f(trill-rbridge.mi2), (46,17) The first revision should match the
> last update for MODULE-IDENTITY rbridgeMIB
> W: f(trill-rbridge.mi2), (299,4) Sequence "RBridgeBasePortEntry" and Row
> "rbridgeBasePortEntry" should have related names
> E: f(trill-rbridge.mi2), (299,4) Row "rbridgeBasePortEntry" may not have
> columns with MAX-ACCESS of read-write if any column is read-create
> E: f(trill-rbridge.mi2), (608,18) Index item "dot1qFdbId" must be
> defined with syntax that includes a range
> W: f(trill-rbridge.mi2), (810,20) Item "rbridgeMultiFibPorts" should
> have SIZE specified
> E: f(trill-rbridge.mi2), (838,18) Index item "dot1qVlanIndex" must be
> defined with syntax that includes a range
> E: f(trill-rbridge.mi2), (912,18) Index item "dot1qVlanIndex" must be
> defined with syntax that includes a range
> E: f(trill-rbridge.mi2), (1113,18) Index item "dot1qVlanIndex" must be
> defined with syntax that includes a range
> E: f(trill-rbridge.mi2), (1272,17) Index item "dot1qVlanIndex" must be
> defined with syntax that includes a range
> W: f(trill-rbridge.mi2), (1265,4) Row "rbridgeSnoopingAddrEntry" has
> indexing that may create variables with more than 128 sub-ids
> W: f(trill-rbridge.mi2), (1310,20) Item "rbridgeSnoopingAddrPorts"
> should have SIZE specified
> W: f(trill-rbridge.mi2), (838,18) Row "rbridgeVlanEntry" does not have a
> consistent indexing scheme - index items must be in same order as used
> in INDEX cl ause for "base row" dot1qVlanCurrentEntry
> W: f(trill-rbridge.mi2), (912,18) Row "rbridgeVlanPortEntry" does not
> have a consistent indexing scheme - cannot specify an index item from
> additional "bas e row" dot1qVlanCurrentEntry, since can have only one
> "base row" which is rbridgeBasePortEntry
> W: f(trill-rbridge.mi2), (1113,18) Row "rbridgeEsadiEntry" does not have
> a consistent indexing scheme - index items must be in same order as used
> in INDEX clause for "base row" dot1qVlanCurrentEntry
> W: f(trill-rbridge.mi2), (1272,17) Row "rbridgeSnoopingAddrEntry" does
> not have a consistent indexing scheme - index items must be in same
> order as used in  INDEX clause for "base row" dot1qVlanCurrentEntry
> 
> 7. Objects like rbridgeBaseUniMultipathEnable or
> rbridgeBaseMultiMultipathEnable could use the TruthValue TC as SYNTAX.
> 
> 8. UNITS clauses would be useful for counter objects.
> 
> 9. There is no indication about the behavior of tables that contain
> counters wrt. counters discontinuity or any discontinuity indicator
> objects defined. (see section 4.6.1.2 in RFC 4181 for this)
> 
> 
> Regards,
> 
> Dan

---

From: Ralph Droms <[email-masked]>
Date: Thu, 1 Sep 2011 11:47:24 -0700

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 1 Sep 2011 13:34:19 -0700

- Ralph

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 5 Sep 2011 17:47:19 +0200

Hi Anil,

See in line. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Anil Rijhsinghani [mailto:[email-masked]]
> Sent: Friday, September 02, 2011 8:55 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]; Ralph Droms
> Subject: Re: [rbridge] [MIB-DOCTORS] Volunteer needed to reviewdraft-
> ietf-trill-rbridge-mib-03
> 
> Hi Dan,
> 
> I'm working through all your syntactical suggestions, and will wait to
> hear from you about any additional comments from MIB doctors.
> 
[[DR]] I suggest that you do not wait for further comments and published
a revised version when you feel that you are ready, addressing the
comments received until now. 

> Regarding your first comment, please note that references to IEEE
802.1
> MIB modules have been added to the "Relationships" section, following
> your earlier round of comments. We cannot eliminate references to the
> IETF MIB modules, given that the vast majority of vendors have
> implemented those.
> 
[[DR]] Understood. However, somebody who starts writing an
implementation today will probably look to the more recent MIB modules
and these are the one published by the IEEE 802.1 WG. I would at least
provide also the name of the MIB groups in the IEEE 802.1 MIB modules,
include references and even provide a paragraph that says that Bridge
MIB work has been transferred to the IEEE 802.1 WG as per [RFC4663].
 
> Regards,
> Anil
> 
> On Aug 18, 2011, at 9:40 AM, Romascanu, Dan (Dan) wrote:
> 
> > Hi,
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:mib-doctors-
> >> [email-masked]] On Behalf Of Romascanu, Dan (Dan)
> >> Sent: Thursday, August 11, 2011 3:27 PM
> >> To: [email-masked]
> >> Cc: Ralph Droms
> >> Subject: [MIB-DOCTORS] Volunteer needed to reviewdraft-ietf-trill-
> >> rbridge-mib-03
> >>
> >> MIB-Doctors,
> >>
> >> We need a volunteer to review
> >> http://www.ietf.org/id/draft-ietf-trill-rbridge-mib-03.txt. The
> >> document
> >> is co-authored by Anil Rijhsinghani (author of the original Bridge
> > MIB)
> >> and looks in pretty good shape.
> >>
> >> Thanks and Regards,
> >>
> >> Dan
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> MIB-DOCTORS mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mib-doctors
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge