Definitions of Managed Objects for Routing Bridges (RBridges)
draft-ietf-trill-rbridge-mib-10

[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?

[Ballot discuss]
Updated DISCUSS and COMMENT from Dan Romascanu (previous OPS A.D.)

I agree with the previous A.D. regarding the references to the more recent IEEE MIB documents to be referred rather than the IETF RFCs 4188 and 4363.
Dan's explanation: The response was that they would not oblige any implementers to compile and implement the IEEE MIB modules. I do not agree with this explanation. What is mandated is compilation only which should not be a big deal. We also should decide at which point in time we agree that the majority of the vendors implement the newer IEEE 802.1 MIB modules rather than the older RFC 4188 and 4363.

A quick scan by the MIB-doctors reports:
1) The Indexing.

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.

2)
> * Suggested OID layout is not as Specified in the MIB Guidelines
> document:
>
>  xxxMIB
>          |
>          +-- xxxNotifications(0)
>          +-- xxxObjects(1)
>          +-- xxxConformance(2)
>              |
>              +-- xxxCompliances(1)
>              +-- xxxGroups(2)
>
>
> Compliances and Groups are reversed in the MIB draft.
>


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



Note that we're still expecting a thorough review from the MIB-doctors (Joan Cucchiara)

[Ballot discuss]
Updated DISCUSS and COMMENT from Dan Romascanu (previous OPS A.D.), based in part on the MIB doctor review by Joan Cucchiara.

2. The list of IMPORTs described in 6.8 is not consistent with the actual list of IMPORTs in the MIB module. The list in the MIB module uses imports from RFC 4188 and RFC 4363 not mentioned in 6.8

In my original DISCUSS I also pointed to the fact that I prefer the more recent IEEE MIB documents to be referred rather than the IETF RFCs 4188 and 4363. The response was that they would not oblige any implementers to compile and implement the IEEE MIB modules. I do not agree with this explanation. What is mandated is compilation only which should not be a big deal. We also should decide at which point in time we agree that the majority of the vendors implement the newer IEEE 802.1 MIB modules rather than the older RFC 4188 and 4363. I will leave it to you whether to insist on this.

[Ballot comment]
3. While DEFVALs have been added in many places, they have not been added in all places.  For example rbridgeConfidenceNative has a default value defined only in the DESCRIPTION clause.

4. rbridgeBaseNumPorts

Gauge32 would be a better SYNTAX. UNITS clause not necessary

5. rbridgeBaseForwardDelay

isn't this supposed DEFVAL of 15 seconds?


6. rbridgeBaseUniMultipathEnable, rbridgeBaseMultiMultipathEnable

These objects should be optional, however, they are required by the Conformance Statement.  Please Explain.


DESCRIPTION
Please state what the value of True(1) and False(2) mean, as in "When the value of this object is True(1), multipath is enabled."


REFERENCE
Should specify the RFC (RFC6325, Appendix C)

DEFVAL
These should have a DEFVAL.  (Probably False(2) since these are optional?)


8. * rbridgeBasePortIfIndex

Which IfIndex is this referring to?  In other words, what is the corresponding ifType?


10. rbridgeConfidenceNative, rbridgeConfidenceDecap Need DEFVALs

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

[Ballot comment]
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?

[Ballot discuss]
Updated Discuss for revsion -07. Thanks for the work so far:

My last remaining Discuss point could simply be addressed by adding a conformance statement, or we can try to get some help from the MIB Doctors

---

I would like help from the OPS ADs (and MIB Doctors) on this point:

It seems to me that section 6.7 needs a new conformance statement to
be applied to ISIS-MIB. The text in the section appears to be in two
parts:
                                                                   
- Implementation guidance (what value to return on a GET from a Trill
  implementation)

- Implementation requirements (which tables/objects to implement or not
  (conformance statement).

[Ballot comment]

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.

[Ballot comment]
1. In Section 6.7:

s/IS-IS MIB/ISIS-MIB

Other places in this doc also should also change to ISIS-MIB.

2. check the REFERENCE clauses
so that they consistantly refer to "RFC 6325", and not
"RBridge" or "RBridge clause".

3. While DEFVALs have been added in many places, they have not
been added in all places.  For example rbridgeConfidenceNative has
a default value defined only in the DESCRIPTION clause.

4. rbridgeBaseNumPorts

Gauge32 would be a better SYNTAX. UNITS clause not necessary

5. rbridgeBaseForwardDelay

Reference is supposed to be Section 4.8.3?
Also, isn't this supposed to be 4..30 with DEFVAL of 15 seconds?


6. rbridgeBaseUniMultipathEnable, rbridgeBaseMultiMultipathEnable

These objects should be optional, however, they are required by
the Conformance Statement.  Please Explain.


DESCRIPTION
Please state what the value of True(1) and False(2) mean,
as in "When the value of this object is True(1), multipath
is enabled."


REFERENCE
Should specify the RFC (RFC6325, Appendix C)

DEFVAL
These should have a DEFVAL.  (Probably False(2) since these
are optional?)

7. rbridgeBaseAcceptEncapNonadj

DESCRIPTION clause still gives a default value.
Please remove from DESCRIPTION and give a proper DEFVAL { false }

This value is supposed to be per port, right?  Is this scalar
per port?

8. * rbridgeBasePortIfIndex

Which IfIndex is this referring to?  In other words,
what is the corresponding ifType?

9. rbridgeBasePortStpRootChanges

Which Discontinuity Object is being referred to here?
Is this is the corresponding ifCounterDiscontinuityTime object
then please state that in the DESCRIPTION.

10. rbridgeConfidenceNative, rbridgeConfidenceDecap
Need DEFVALs

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

11. rbridgeUniFdbPort, should probably an Unsigned32.
DEFVAL { 0 }

12. rbridgeUniFdbPort should probably be Unsigned32.

Are the ports in this object related to the ports
in the rbridgeBasePortTable? Please clarify.

13. rbridgeUniFdbNick

Could you consistently use Nickname as was done
in prior objects?  Does this value appear in the
rbridgeNickTable?  Please clarify.

14. rbridgeUniFdbConfidence

Could this also be 255 if configured by management?
(My question is because the following object (status) includes
management.)

Also, should this have a DEFVAL of 0x20 as in 4.8.2 ?


15. rbridgeUniFdbStatus

REFERENCE ?


16. rbridgeUniFibNickname

Is this the same Nickname that has an entry in rbridgeNickTable?
If so, please clarify that in the DESCRIPTION.

17. rbridgeUniFibPort

Unsigned32 seems a better SYNTAX.

Are the ports in this object related to the ports
in the rbridgeBasePortTable?  Please clarify.


18. rbridgeMultiFibPorts

Does this PortList correspond to entries in the rbridgeBasePortTable?
Please explain.

19. rbridgeVlanForwarderLost

Counters names should end in an "s" to indicate possibly more than one.
Please rename to rbridgeVlanForwarderLost to rbridgeVlanForwarderLostChanges

DESCRIPTION -- So counters are usually retrieved along with their
corresponding
Discontinuity Objects.  If there is a change in the Discontinuity Object,
that
indicates the counter suffered a discontinuity.  Please specify what the
Discontinuity object is for this counter.

REFERENCE -- I think this is 4.8.3


20. rbridgeVlanSnooping

Should there be a separate ipv6 value?

21. rbridgeVlanPortTable

I'm not clear on why this is indexed the way it is.  Why wouldn't you
want Port first?


22. rbridgePortCounterTable

As mentioned prior, name of counter objects should end in "s".


23. rbridgeEsadiDrbHoldingTime

DEFVAL ?


24. rbridgeSnoopingPortAddrType and rbridgeSnoopingPortAddr

Should these be restricted to IPv4 and IPv6 in the conformance
statements?

25. rbridgeSnoopingAddrType and rbridgeSnoopingAddr
Same question as above.


26. rbridgeDtreePriority

Unsigned32 ?
DEFVAL needed.

27. rbridgeDtreeActiveTrees

Not sure if this is supposed to be a Counter32 ?
If so, then is there a Discontinuity associated with it?


28. rbridgeDtreeMaxTrees

is the DEFVAL [ 1 } ??



29. rbridgeDtreeNumber

Where did these value come from?
      SYNTAX      Unsigned32 (0..65535)

30. rbridgeDtreeNick
Please use Nickname to be consistant with rest of the MIB module.

31. rbridgeTrillSz

Why is this read-only?

32. rbridgeTrillNbrMtu
Is this supposed to be "to this neighbor" or "for this neighbor"?

33. rbridgeBaseNewDrb

Please don't use the word "trap".  These are Notifications.

I don't understand why this notification is optional.  Is there
a concern that too many of these would be sent, or is it just
not a very important event to be notified about?
Please explain.

34. rbridgeBaseTopologyChange

Similar comment as above. My concern is that maybe a throttling
mechanism may be better than to just say this optional.

35. Compliance/Conformance Statements

As mentioned in above comments, limiting values for InetAddrType
and InetAddr and RowStatus objects may be appropriate.

[Ballot discuss]
Updated DISCUSS and COMMENT based in part on the MIB doctor review by Joan Cucchiara.

1. running smicng strict mode results in:

SMICng strict check results in:

W: f(rbridge.mi2), (323,4) Sequence "RBridgeBasePortEntry" and Row "rbridgeBasePortEntry" s hould have related names
W: f(rbridge.mi2), (894,20) Item "rbridgeMultiFibPorts" should have SIZE specified
W: f(rbridge.mi2), (1400,4) Row "rbridgeSnoopingAddrEntry" has indexing that may create var iables with more than 128 sub-ids
W: f(rbridge.mi2), (1445,20) Item "rbridgeSnoopingAddrPorts" should have SIZE specified
W: f(rbridge.mi2), (1014,18) Row "rbridgeVlanPortEntry" does not have a consistent indexing  scheme - cannot specify an index item from additional "base row"
rbridgeVlanEntry, since c
an have only one "base row" which is rbridgeBasePortEntry

- for the first warning, I think that you need to change
        RBridgeBasePortEntry
  occurrences into
        RbridgeBasePortEntry
  that is, use a lowercase b, just as theu do in the definitions
  of the ibject un that table.. Probably a TYPO.

- The second one uses the PortList TC, which is imported from qbridge-mib and that
  TC is an unrestricted OCTET string.
  It is a warning, so I think we can ignore it.
  However, each bit represents one port, so if we assume max 4K ports, then
  a SIZE of 1..512 would seem a proper value.

- for the 3rd one we normaly want some text in a DESCRIPTION clause that would
  explain why more than 128 subids is not expected and/or warn implementers
  to make sure that exceeding the limit does not happen.

  The reason is the use of rbridgeSnoopingAddr (which is an InetAddress) as an INDEX
  object. which can have up to 255 octets, i.e. 256 SUBIDs just as index.

- the 4th one has same warning reasoning as the 2nd one.

- the 5th (last) one is something that could be ignored

2. The list of IMPORTs described in 6.8 is not consistent with the actual list of IMPORTs in the MIB module. The list in the MIB module uses imports from RFC 4188 and RFC 4363, I suggest using the IMPORTs from the IEEE 802 MIB modules. It also uses an import from RFC 2233 instead of RFC 2863 which obsoletes 2233 - I suggest replacing.

3. rbridgeBaseNicknameNumber

I don't understand the relationship between this object
and the rbridgeBaseNicknameTable.  Is this the MAX number of
entries in the Table?  Or does this value represent the current
entries in the Table?  If it is Max, please say Max somewhere in
the object's name.  Also, I think the value is supposed to be
1..256, with DEFVAL of 1.


DESCRIPTION clause still gives a default value.
Please remove from DESCRIPTION and give a proper DEFVAL { 1 }

Should also have a REFERENCE.

SUGGEST:  Please consider moving this scalar to be before the table (with
appropriate OID changes).

4. rbridgeVlanDisableLearning

Please clarify as to what True(1) and False(2) mean here, e.g.:
To disable learning....the value of this object must be set to false (2).
Otherwise, true(1).



5. 24.  rbridgeEsadiEnable

Please clearly state the semantics of the values of True/False for this
object.

6. rbridgeEsadiConfidence
REFERENCE  and Section 4.8.2

Why is 255 excluded as a value?

[Ballot discuss]
Updated Discuss for revsion -06. Thanks for the work so far:

---

The MIB Doctor Review has been completed. I see it covers some of the points I made as Discusses and later reduced to Comments. I will hold this Discuss until I see updates addressing the review.

---

I would like help from the OPS ADs (and MIB Doctors) on this point:

It seems to me that section 6.7 needs a new conformance statement to
be applied to ISIS-MIB. The text in the sectionappears to be in two
parts:
                                                                   
- Implementation guidance (what value to return on a GET from a Trill
  implementation)

- Implementation requirements (which tables/objects to implement or not
  (conformance statement).

---

I expected to see some mention of rbridgeSnoopingAddrType in the
conformance statement to limit its applicability to only a few of the
address types.

rbridgeSnoopingAddrType has syntax InetAddressType
The InetAddressType Textual Convention certainly allows IPv4 and IPv6, but it
also allows a number of other formats that I believe you don't want to support.
I think the description clause of the object should mention the limitations, and
the conformance statement should limit the values supported.

[Ballot comment]
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?

[Ballot discuss]
Updated Discuss for revsion -06. Thanks for the work so far:

---

Discuss held pending MIB Doctor review that is in progress.

---

I would like help from the OPS ADs (and MIB Doctors) on this point:

It seems to me that section 6.7 needs a new conformance statement to
be applied to ISIS-MIB. The text in the sectionappears to be in two
parts:
                                                                   
- Implementation guidance (what value to return on a GET from a Trill
  implementation)

- Implementation requirements (which tables/objects to implement or not
  (conformance statement).

---

I expected to see some mention of rbridgeSnoopingAddrType in the
conformance statement to limit its applicability to only a few of the
address types.

rbridgeSnoopingAddrType has syntax InetAddressType
The InetAddressType Textual Convention certainly allows IPv4 and IPv6, but it
also allows a number of other formats that I believe you don't want to support.
I think the description clause of the object should mention the limitations, and
the conformance statement should limit the values supported.

[Ballot discuss]
updated for -06-

1) I would like to see a MIB Doctor review. I have added some information below to help the MIB Doctor get up-to-speed on the IEEE/IETF issues.

2) Per section 6,
  The Bridge MIBs were originally written in the IETF, and implemented
  by many vendors. Per [RFC4663], this has recently been transferred to
  the IEEE 802.1 group. As vendors may have implemented either the IETF
  or IEEE Bridges MIBs, this RBridge MIB is designed to work with
  either one.
Has IEEE 802.1 been asked to review this MIB module to ensure compatibility with the
IEEE Bridge MIB modules?

== A few additional points related to my points 1 and 2.

1) the IETF Bridge MIB modules are "frozen in time", and the IETF
standards based on these modules is still valid. IEEE changed the IETF
Bridge MIB modules to support provider-based bridging. They modified the
indexing to include an instance identifier, where the IETF modules lack
such an index field. Since they modified indexing, they needed to redefine
the OID registrations. They chose to relocate the root of the module to an
IEEE OID tree. So there are two valid standard trees for managing bridges
- the IETF standard modules and the IEEE standard modules.

2) The IETF standard has been implemented widely and is especially useful
for enterprises (where only one instance of the Bridge MIB is needed) -
that's why we kept it valid; the IEEE standard is useful for service
providers, where support for multiple bridging instances is needed. I
think the IEEE modules may be used with a single instance, but I don't
know how the IETF and IEEE standards compare otherwise.

3) I am a bit concerned about building upon the "frozen in time" IETF
modules. It is probably preferable to build upon the IEEE modules so we
only have one tree growing. I don't know whether TRILL is really focused
on enterprise functionality and would have no use for multiple rbridge
support - but if they can implement single rbridge support based on the
IEEE modules, that should probably be done in case somebody decides to
support multiple rbridge instances.
(Bert Wijnen and Dan Romascanu were involved in the transfer, and agree with this)

4) Adrian points out some defaults that are defined in text but not
written in DEFVAL clauses. 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.

[Ballot discuss]
Thanks to the Gen-ART Review by Roni Even on 20-Nov-2011 for catching
  the concern reported below.

  Section 5.10 says:

  The defined notifications are focused on the TRILL protocol
  functionality.  Notifications are defined for changes in the
  Designated RBridge status and the topology.  TBD for this section is
  what notifications are required from imported MIBs and how can the
  TRILL notifications be throttled.

  The TBD needs to be filled in before this document ia approved.

[Ballot discuss]
I am sorry to have missed this. One of the comments in the previous reviews was the fact that some rbridgeBaseNicknameTable and rbridgeEsadiTable include read-create objects but now RowStatus objects. This was not fixed in the latest version and it MUST be corrected.

[Ballot discuss]
1) I haven't had a chance to go through this as thoroughly as I would like, and I am concerned it has not had a MIB Doctor review. While Dan is a MIB Doctor, this has been a particularly difficult week for IESG, and I don't know if he has had enough time to do a through review. Since Adrian has identified some questionable design points, I would like to see a MIB Doctor review.

2) Per section 6,
  The Bridge MIBs were originally written in the IETF, and implemented
  by many vendors. Per [RFC4663], this has recently been transferred to
  the IEEE 802.1 group. As vendors may have implemented either the IETF
  or IEEE Bridges MIBs, this RBridge MIB is designed to work with
  either one.
Has IEEE 802.1 been asked to review this MIB module to ensure compatibility with the
IEEE Bridge MIB modules?

[Ballot discuss]
1) I haven't had a chance to go through this as thoroughly as I would like, and I am concerned it has not had a MIB Doctor review. While Dan is a MIB Doctor, this has been a particularly difficult week for IESG, and I don't know if he has had enough time to do a through review. Since Adrian has identified some questionable design points, I would like to see a MIB Doctor review.

2) I have a discuss-discuss
We have an (Informational) agreement with IEEE 802.1 that work on bridge management should be done in IEEE 802.1. From RFC4663:
  Since the IETF Bridge MIB WG does not intend to develop MIB modules
  in the future, submitters of new work in the bridge management space
  should be directed to the IEEE 802.1 WG, and it should be recommended
  that they not publish their proposed MIB modules as Internet-Drafts.
Do we care about this agreement that represented IETF consensus in 2006?

3) Per section 6,
  The Bridge MIBs were originally written in the IETF, and implemented
  by many vendors. Per [RFC4663], this has recently been transferred to
  the IEEE 802.1 group. As vendors may have implemented either the IETF
  or IEEE Bridges MIBs, this RBridge MIB is designed to work with
  either one.
Has IEEE 802.1 been asked to review this MIB module to ensure compatibility with the
IEEE Bridge MIB modules?

[Ballot comment]
You should mainly be saying "MIB module" where you say "MIB"

---

Some of the IMPORTS clause entries usefully point to the RFCs housing
the imported TCs. It would be great if you could include the references
for all the others.

---

I appreciate the many REFERENCE clauses. Could add one to
RbridgeNickname.

---

  -- Implementation of the rbridgeBase subtree is mandatory for all
  -- RBridges.

Does this mean
... that are conformant to this MIB module
Or are you making a wider statement about Rbridges?

---

The DESCRIPTION clause of rbridgeSnoopingPortAddr should indicate the
(obvious) fact that the object is interpretted in the context of
rbridgeSnoopingPortAddrType.

---

  rbridgeDtreeActiveTrees OBJECT-TYPE
      SYNTAX      Unsigned32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The total number of trees being computed by all Rbridges
          campus."

Missing some text in the DESCRIPTION clause?

[Ballot discuss]
Has a MIB doctor review been done yet? It seems like one is still
needed. I am not a MIB expert, but I think I see a number of issues.

---

I'm afraid Sean's Comment needs to be captured in a Discuss.

Please resolve the downref to RFC 4663 either by moving it to
Informative (which seems reasonable) or by reissuing the last call.

---

I would like help from the OPS ADs (and MIB Doctors) on this point:

It seems to me that section 6.7 needs a new conformance statement to
be applied to ISIS-MIB. The text in the sectionappears to be in two
parts:
                                                                   
- Implementation guidance (what value to return on a GET from a Trill
  implementation)

- Implementation requirements (which tables/objects to implement or not
  (conformance statement).

---

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

---

There seems to be some confusion about defaults.

There are a number of cases where the DESCRIPTION clause states a
specific value for the default of a read-write or a read-create object.
For example:

  rbridgeBaseForwardDelay OBJECT-TYPE
      SYNTAX      Unsigned32
      UNITS      "seconds"
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
          "Modified aging time for address entries after an appointed
          forwarder change. The default value is 15.

          The value of this object MUST be retained across
          reinitializations of the management system."
      REFERENCE
            "RBridge section 4.8.2"
      ::= { rbridgeBase 3 }

This appears to be missing a DEFVAL clause unless you mean something
different by "default". If you actually mean that the default in an
implementation of the protocol is 15, then it is not appropriate to
mention it here.

In other objects (rbridgeBaseUniMultipathEnable,                     
rbridgeBaseMultiMultipathEnable) you have "The default is
implementation-specific." If this applies to the implementation of the 
management agent then you might guide the implementer. If it applies to
the implementation of the protocol, then it doesn't really belong here.

I suggest you look at each DESCRIPTION clause where there is a default
described and work out whether you should:
- add a DEFVAL clause
- reomove the txt
- extend the text to give additional advice to the implementer of the
  management agent.

(By the way, sometimes you have included the DEFVAL just fine.)

---

  rbridgeBasePortIfIndex OBJECT-TYPE
      SYNTAX      InterfaceIndex

Should this be InterfaceIndexOrZero? What would happen if the entry was
deleted from IF-MIB?

---

I expected to see some mention of rbridgeSnoopingAddrType in the
conformance statement to limit its applicability to only a few of the
address types.

---

  rbridgeDtreeActiveTrees OBJECT-TYPE
      SYNTAX      Unsigned32

Shouldn't this more properly be a Gauge32?

[Ballot comment]
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."

[Ballot discuss]
Thanks to the Gen-ART Review by Roni Even on 20-Nov-2011 for catching
  the concern reported below.

  Section 5.10 says:

  The defined notifications are focused on the TRILL protocol
  functionality.  Notifications are defined for changes in the
  Designated RBridge status and the topology.  TBD for this section is
  what notifications are required from imported MIBs and how can the
  TRILL notifications be throttled.

  The TBD needs to be filled in before this document ia approved.

[Ballot comment]
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.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Definitions of Managed Objects for RBridges) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'Definitions of Managed Objects for RBridges'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo defines a portion of the Management Information Base (MIB)
  for use with network management protocols.  In particular it defines
  objects for managing RBridges, which are devices that implement the
  TRILL protocol.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-mib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-mib/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

  Donald Eastlake is the Document Shepherd.
  I have reveiwed the document and believe it is ready.

(1.b) Has the document had adequate review both from key WG members
      and from key non-WG members?

  I believe the review has been good. At our request, Dan Romascanu
  did a review and his comments were resolved.

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

  No, althogh it needs and, I assume, will receive MIB Doctor review.

(1.d) Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of? Has an IPR disclosure
      related to this document been filed?

  No specific concerns. No IPR disclosure has been filed for this
  document.

(1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

  The consensus for the document is solid but not very broad. MIB's
  are somewhat of an acquired taste.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent?

  No.

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See the Internet-Drafts Checklist
      and http://tools.ietf.org/tools/idnits/). Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

  Yes. The only formal review required is MIB Doctor which has not
  yet been done.

(1.h) Has the document split its references into normative and
      informative? Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state?

  References are split into normative and informative and all
  normative references are IETF standards except one which is an IEEE
  standard.

(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document?

  The document has an IANA Considerations section and requires only
  the allocation of one code point in the MIB OID tree.

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

  No but the author has verified the MIB with libsmi as recommended
  by Dan Romascanu.

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Write-Up:

Technical Summary

  This memo defines a portion of the Management Information Base (MIB)
  for use with network management protocols.  In particular it defines
  objects for managing RBridges, which are devices that implement the
  TRILL base protocol standard.

Working Group Summary
   
  There was some controversy on the WG mailing list concerning MIB
  structure but this turned out to be a misunderstanding and has been
  resolved. The document now has WG consensus.

Document Quality
  [insert results of MIB Doctor review here]