Definitions of Managed Objects for Routing Bridges (RBridges)
RFC 6850

I have cleared my last Discuss point based on revision -08. I can't claim to be happy with the way this point has been resolved (neither the process, nor the resolution), but by largely punting on the issue it has taken it out of scope of the document. I think that you have made the document poorer by doing this, and you have made MIB management of rbridges less complete.

---

Moved from Discuss to acknowledge that this is an explicit decision made by the authors:

   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.)

---

Moved from Discuss as this is not a major issue

   rbridgeDtreeActiveTrees OBJECT-TYPE
       SYNTAX      Unsigned32

Shouldn't this more properly be a Gauge32?

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?

Adrian, Dn, and the MIB Doctor point out some defaults that are defined in text but not
written in DEFVAL clauses. This may seem unimportant, but it is not.

Most operators use tools that automate SNMP
queries and interpretation, so making the MIB modules machine-readable is
important. In addition there are tools that check MIB module
implementations for compliance to the standards. These tools can check
defaults if they are specified in DEFVAL clauses; these tools would have
trouble reading the English description of a default. Therefore it is
important to use DEFVALs when defining defaults. That may not be obvious
to an agent implementer, but it is important for interoperability between
agent and manager implementations.

The MIB has:

   rbridgeVlanIndex OBJECT-TYPE
       SYNTAX      Unsigned32 (1..4094|4096..4294967295)

What's so special about 4095? You might borrow some text from RFC 4363, which says:

    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."

I hit the nits checker button.  There's a downref to 4663 that wasn't called out in the IETF LC.  Easiest thing to do is probably to move it to an informative reference because 4663 is all about process and there's really nothing to implement.

- What does "TBD for this section" mean in 5.1?
I assume that was meant to be deleted but that
got missed?