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

[Anil Rijhsinghani]

Hi Dan,

I'm working through all your syntactical suggestions, and will wait to hear from you about any additional comments from MIB doctors.

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.

Regards,
Anil

On Aug 18, 2011, at 9:40 AM, 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
> 
> 
> 
>> -----Original Message-----
>> From: mib-doctors-bounces at ietf.org [mailto:mib-doctors-
>> bounces at ietf.org] On Behalf Of Romascanu, Dan (Dan)
>> Sent: Thursday, August 11, 2011 3:27 PM
>> To: mib-doctors at ietf.org
>> 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
>> MIB-DOCTORS at ietf.org
>> https://www.ietf.org/mailman/listinfo/mib-doctors
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge