[Ballot comment]
1. The IMPORT list is now consistent with the MIB module. It would be good to add a short sentence like the following in section 6.8:

Ø Note that the IEEE 802.1 MIB modules also import the BridgeID TC from the BRIDGE_MIB in RFC 4188 and the VlanId, PortList TCs from the Q-BRIDGE-MIB in RFC 4363.

2. The Indexing and AUGMENTS

INDEX { rbridgeBasePort } is used as an index in several tables and the
relationship should really be an AUGMENTS. Not sure why this was not done.

rbridgePortCounterEntry Why is AUGMENTS not used here?
Using AUGMENTS is actually quite meaningful here.

rbridgeEsadiTable. I think this table AUGMENTS or sparsely AUGMENTS
the rbridgeVlanTable.
Please add wording to the DESCRIPTION of the
table/entry and, if appropriate,
change the INDEX to an AUGMENTS.

rbridgeSnoopingPortTable
This table seems to sparsely augment the
rbridgeBasePortTable and the rbridgePortCounterTable. That should
be discussed in the table/entry DESCRIPTION.

Note that this AUGMENTS discussion is more a MIB design choice, and the preferred choice from the MIB doctor.
So while AUGMENTS is preferred, I could live potentially without it.

3.
* Suggested OID layout is not as Specified in the MIB Guidelines
document (RFC4148):

xxxMIB
|
+-- xxxNotifications(0)
+-- xxxObjects(1)
+-- xxxConformance(2)
|
+-- xxxCompliances(1)
+-- xxxGroups(2)

Compliances and Groups are reversed in the MIB draft. Any reason why RFC4148 is not followed?

4. the Conformance is a full conformance which contains read-create and
read-write objects. I raised this as a concern as part of the MIB Dr rview
and asked that the WG be informed that in order to be compliant with the MIB,
they will need to support SNMP sets.

While not technically wrong, my experience is having both a read-only and full
conformance in a MIB which contains sets, allows more flexibility for those
that do not configure their products using SNMP. This allows them to be
compliant with the RFC, and I believe that the WG needs to be made aware of
this, since most MIBs from the IETF in recent history have a read-only
conformance. I asked the authors to confirm with the WG that this is what the
WG wants, but did not see any emails to the WG on the list. I may have missed
the email, or they may have confirmed this in some other way, but I am not
aware.

Benoit: let me add to Joan's point. Today the majority of MIB module have read-only conformance clauses.
To be compliant with the RFC, implementers MUST implement the read-write objects
However, hese days, many vendors are reluctant to implement write operations. What we observe is that SNMP is not used for configuration management.
While there is nothing wrong with your conformance statement, that seriously limits the MIB module deployment.

5. rbridgeBaseNumPorts

Gauge32 would be a better SYNTAX. UNITS clause not necessary

6. rbridgeBaseForwardDelay

isn't this supposed DEFVAL of 15 seconds?

7. rbridgeBasePortIfIndex

Which IfIndex is this referring to? In other words, what is the corresponding
ifType, i.e. physical layer?

Bridge port may not be an interface.
- none.
- ip address (routing MIB)
- media interface (ex: ethernet MIB)

Implementer needs clarification.

8. rbridgeConfidenceNative, rbridgeConfidenceDecap Need DEFVALs

Do these scalars refer to the entire Rbridge or is this per port?

9.
Output from smicngPro:
W: f(RBRIDGE-MIB.my), (47,17) The first revision should match the last update for MODULE-IDENTITY rbridgeMIB
W: f(RBRIDGE-MIB.my), (919,20) Item "rbridgeMultiFibPorts" should have SIZE specified
W: f(RBRIDGE-MIB.my), (1452,4) Row "rbridgeSnoopingAddrEntry" has indexing that may create variables with more than 128 sub-ids
W: f(RBRIDGE-MIB.my), (1502,20) Item "rbridgeSnoopingAddrPorts" should have SIZE specified
W: f(RBRIDGE-MIB.my), (1043,18) Row "rbridgeVlanPortEntry" does not have a consistent indexing scheme - cannot specify an index item from additional "base row" rbridgeBasePortEntry, since can have only one "base row" which is rbridgeVlanEntry

Output from SmiLint:
mibs/RBRIDGE-MIB.my:47: [3] {revision-after-update} revision date after last update
mibs/RBRIDGE-MIB.my:52: [3] {revision-missing} revision for last update is missing

Even if IANA would fix this, it would way nicer to have a clean MIB module for them.

10.
rbridgeBaseTrillVersion
According to RFC6325, this is a 2 bit field and you
have 4 bytes. Please clarify.

Unsigned32(0..3).

This one is a waste of 2 bytes. Do you plan on having 4 bytes in the future (like the BGP AS that went from 2 bytes to 4 bytes)?

11.
rbridgeBaseForwardDelay
According to RFC6325, should have a DEFVAL of 15 seconds.

12.
rbridgeBaseAcceptEncapNonadj
according to RFC6325, should have:
DEFVAL(false)

13.
rbridgeBaseNicknameNumber
Please add:
"Additionally, this value represents the maximum amount
of entries in the rbridgeBaseNicknameTable."

14.
Why doesn't this have a DEFVAL(1) as specified in
RFC6325? Also, you should add a REFERENCE clause
RFC6325, Section 5.1.

15.
rbridgeBaseNicknameTable
Please clarify in the Table's DESCRIPTION clause that
this table represents nickname information which is configured
by an operator OR learned dynaically by the Rbridge.

16.
rbridgeBaseNicknamePriority
This DESCRIPTION needs additional information.
When nickname is configured, the most significant
bit (0x80) MUST be set AND the bottom 7 bits
have the default value of 0x40, so 0x80 + 0x40 == 0xC0
which is 192 decimal. Additionally, the bottom 7 bits
could be configured to value other than 0x40.

17.
However, if a row is created due to the nickname
dynamically created, then the most significant bit (0x80) MUST NOT
be set.

18.
rbridgeBasePortTable
Please check REFERENCE clauses for this table.
I think you mean section 5.3 (not 5.2).

19.
Please specify what the value is when the bit is set (i.e. true).
Please check this throughout the MIB because while the DESCRIPTION
clauses are more specific, there are places where the value
of true/false is not specified for TruthValue

20.
rbridgeBasePortStpRootChanges

Probably discontinuities can occur if this port changes
status also (please see ifCounterDiscontinuityTime
in RFC2863).

Just add in the description something such as: "should be synchronized ifCounterDiscontinuityTime"

21.
rbridgeConfidenceNative
Need to add DEFVAL (32)

22.
rbridgeConfidenceDecap
Need to add DEFVAL (32)

23.
rbridgeFdbId -- Why is this not rbridgeUniFdbId?
The naming should be consistent for the objects in this
table.

More importantly, where does this value come from?
Could you give a reference?
My concern is that it may be more advantageous to
index by the MAC addr directly, or ( Port, Mac)
so I'm not sure where I see the advantage of
having an additional index which doesn't appear
to be used anywhere else.
Please clarify.

24.
rbridgeUniFdbPort DESCRIPTION clause
mentions rbridgeUniFdbAddress but I think the object is
rbridgeUniFdbAddr?

25.
rbridgeUniFdbNickname AND in other places,
the term "rbridgeFdbAddress" is used, but this isn't defined
anywhere that I can see. I think you mean rbridgeUniFdbAddr?

Also, "FdbId", I think should be rbridgeFdbId?

25.
rbridgeVlanIndex
Why was VlanIndex from Q-BRIDGE-MIB not used?

Please explain. Is this just to exclude 4095?
The vlanIndex takes care of that:

VlanIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value used to index per-VLAN tables: values of 0 and
4095 are not permitted; if the value is between 1 and
4094 inclusive, it represents an IEEE 802.1Q VLAN-ID with
global scope within a given bridged domain (see VlanId
textual convention). If the value is greater than 4095
then it represents a VLAN with scope local to the
particular agent, i.e. one without a global VLAN-ID
assigned to it. Such VLANs are outside the scope of
IEEE 802.1Q but it is convenient to be able to manage them
in the same way using this MIB.

26.

rbridgePortCounterEntry. The naming should be consistent
with the rbridgeBasePortTable (so rbridgeBasePortCounterTable) etc.

Note that this is more a MIB design issue.

27.
rbridgeVlanPortTable
Please check the TruthValue objects in this table (and elsewhere)
to ensure that the value of true(1) and false(2) are clearly stated.

28.
rbridgeEsadiDrbPriority, rbridgeEsadiDrbHoldingTime
The REFERENCE clause could be better, since I couldn't
find the size of the priority anywhere in this section.

29.
The IPv4 and IPv6 needs to be specified in the Conformance
Section.

30.
rbridgeDtreePriority
A default value is specified in DESCRIPTION but this
needs a proper DEFVAL clause.

31.
rbridgeDtreeActiveTrees
Should this be a Gauge32?
This is recommended by RFC 4148

32.
rbridgeTrillMinMtuDesired
Should this have a DEFVAL of 1470 Octets? (just asking)

33.
rbridgeTrillMaxMtuProbes
Why does this value need to be saved after reinitializations?

34.
rbridgeBaseTopologyChange
Please remove the term "trap". SNMPv1 had a mechanism called
trap, but these are Notifications.

what is meant by "if a newDrb trap is sent for the same transition".
Do you mean the "rbridgeBaseNewDrb" notification?