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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 30 Oct 2011 12:18:22 +0100

Hi Anil,

The changes look fine. Please go ahead to the next step as advised by
your AD. 

The other MIB doctors are of course invited to jump in, possibly during
the IETF LC. 

Dan

> -----Original Message-----
> From: Anil Rijhsinghani [mailto:[email-masked]]
> Sent: Friday, October 28, 2011 5:42 AM
> 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
> 
> Dan,
> 
> Most of your feedback has been incorporated into the latest draft,
> draft-ietf-trill-rbridge-mib-04.txt. Please see comments below.
> 
> >> 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].
> 
> A paragraph has been added to section 6 on relationship with IETF and
> IEEE Bridge MIBs as well as a reference to RFC 4663. In addition, MIB
> groups in IEEE 802.1 MIB modules have been added in the relationships
> section.
> 
> >>> 2. There are several tables with read-create objects but no
> > rowStatus
> >>> object - rbridgeBaseNicknameTable, rbridgeBasePortTable,
> >>> rbridgeVlanPortTable, etc.
> 
> rbridgeBasePortTable and rbridgeVlanPortTable should have been using
> read-write objects, and have been updated accordingly.
> rbridgeNicknameTable
> and rbridgeEsadiTable, which contain read-create objects, have status
> objects which, in addition to facilitating creation and deletion of
> rows, also
> serve additional purposes.
> 
> >>>
> >>> 3. There are several writeable objects and tables with writeable
> >> objects
> >>> but no rowStorageType or any indication about persistency
> 
> Information about persistency has been added to all read-write and
> read-create objects.
> 
> >>>
> >>> 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.
> 
> All Integer32 objects have been changed to Unsigned32.
> 
> >>>
> >>> 5. Use of Inter32 (0-65535) for port numbers instead of using
> >>> InetPortNumber from RFC4001
> 
> Please note that these are Bridge port numbers, and not TCP/UDP
> port numbers, as defined by InetPortNumber. The syntax used for these
> objects is the same as that in the original Bridge MIBs.
> 
> >>>
> >>> 6. SMICng strict checking gives:
> >>>
> >>> W: f(trill-rbridge.mi2), (46,17) The first revision should match
> the
> >>> last update for MODULE-IDENTITY rbridgeMIB
> 
> Fixed.
> 
> >>> W: f(trill-rbridge.mi2), (299,4) Sequence "RBridgeBasePortEntry"
> and
> >> Row
> >>> "rbridgeBasePortEntry" should have related names
> 
> Fixed.
> 
> >>> 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
> 
> Fixed.
> 
> >>> E: f(trill-rbridge.mi2), (608,18) Index item "dot1qFdbId" must be
> >>> defined with syntax that includes a range
> 
> Fixed. (rbridgeFdbId has been defined, with a range.)
> 
> >>> W: f(trill-rbridge.mi2), (810,20) Item "rbridgeMultiFibPorts"
> should
> >>> have SIZE specified
> 
> Cannot specify size as this is dependent on number of ports. See
> original Bridge MIBs.
> 
> >>> E: f(trill-rbridge.mi2), (838,18) Index item "dot1qVlanIndex" must
> > be
> >>> defined with syntax that includes a range
> 
> Fixed. (rbridgeVlanIndex has been defined, with a range.)
> 
> >>> E: f(trill-rbridge.mi2), (912,18) Index item "dot1qVlanIndex" must
> > be
> >>> defined with syntax that includes a range
> 
> Fixed.
> 
> >>> E: f(trill-rbridge.mi2), (1113,18) Index item "dot1qVlanIndex"
must
> >> be
> >>> defined with syntax that includes a range
> 
> Fixed.
> 
> >>> E: f(trill-rbridge.mi2), (1272,17) Index item "dot1qVlanIndex"
must
> >> be
> >>> defined with syntax that includes a range
> 
> Fixed.
> 
> >>> W: f(trill-rbridge.mi2), (1265,4) Row "rbridgeSnoopingAddrEntry"
> has
> >>> indexing that may create variables with more than 128 sub-ids
> 
> The index is (IP address, IP address type) which in the case of IPv6
> may
> cause sub-ids to be long. I don't see a way to get around this. Has
> this been
> an issue in other MIBs?
> 
> >>> W: f(trill-rbridge.mi2), (1310,20) Item "rbridgeSnoopingAddrPorts"
> >>> should have SIZE specified
> 
> Depends on number of ports.
> 
> >>> 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
> 
> I believe this will be fixed with the use of rbridgeVlanIndex.
> 
> >>> 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
> 
> I believe this will be fixed with the use of rbridgeVlanIndex.
> 
> >>> 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
> 
> I believe this will be fixed with the use of rbridgeVlanIndex.
> 
> >>> 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
> 
> I believe this will be fixed with the use of rbridgeVlanIndex.
> 
> >>>
> >>> 7. Objects like rbridgeBaseUniMultipathEnable or
> >>> rbridgeBaseMultiMultipathEnable could use the TruthValue TC as
> >> SYNTAX.
> 
> OK, done.
> 
> >>>
> >>> 8. UNITS clauses would be useful for counter objects.
> 
> Done. In addition, large counters have been made Counter64, instead
> of using "overflow" Counter32.
> 
> >>>
> >>> 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)
> 
> Added.
> 
> Regards,
> Anil
> 
> 
> On Sep 5, 2011, at 11:47 AM, Romascanu, Dan (Dan) wrote:
> 
> > 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,
> >>>
> >>> 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: [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
> >
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge