Subject: [MIB-DOCTORS] draft-ietf-trill-rbridge-mib-08 (was: RE: Help with conformance statements)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 1 Oct 2012 11:06:01 +0200

Hi Joan,

Version draft-ietf-trill-rbridge-mib-08 of this document was submitted
and Benoit needs conformation that all critical issues were resolved
before he approves the document. Did you have the time to check 08 and
can you confirm this?

Other MIB doctors advice is of course welcome.

Thanks and Regards,

Dab

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Joan Cucchiara
> Sent: Tuesday, April 10, 2012 9:35 PM
> To: Bert Wijnen (IETF); [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [MIB-DOCTORS] Help with conformance statements
> 
> Adrian and Bert,
> 
> I think it would be very helpful if the authors could specify ISIS
> objects in a MODULE_COMPLIANCE as Bert suggests.
> 
> When I reviewed version 6 of the MIB, I asked if the authors could
> ensure that WG was aware there is no read-only
> compliance and this point was not addressed in version 7 either.
Not
> a
> MUST, but certainly want to make sure
> that the WG is aware they need to support read-create and read-write
via
> SNMP.
> 
> Additionally, there are some warnings from the MIB compilers that were
> also there in version 6 and I'd like to see those addressed in the
> document (either discussed or fixed).  My comments below were emailed
to
> the authors.
> 
> fyi,
>   -Joan
> 
> 
> 
> * LAST-UPDATED and REVISION clauses  have the same date as Version 6
> 
> 
> OUTPUT from SMICNGPRO
> -----------------------
> 
> W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should have
> SIZE specified
> W: f(RBRIDGE-MIB.my), (1453,4) Row "rbridgeSnoopingAddrEntry" has
> indexing that may create variables with more than 128 sub-ids
> W: f(RBRIDGE-MIB.my), (1503,20) Item "rbridgeSnoopingAddrPorts" should
> have SIZE specified
> W: f(RBRIDGE-MIB.my), (1044,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
> 
> 
> SMILINT
> -----------
> 
> mibs/RBRIDGE-MIB.my:1453: [5] {index-exceeds-too-large} warning: index
> of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142
> subidentifier(s)
> 
> Additional descriptions of some error/warning messages:
> 
> Error:       index-element-no-size (level 3)
> Message:     index element `%s' of row `%s' must have a size
restriction
> Description: Object identifiers are restricted in size to have at most
> 128
>              sub-identifiers. This implies that index elements used to
> form
>              instance identifiers must have a size contraint which
> ensures
>              that the 128 sub-identifier constraint is kept intact for
> any
>              possible combination of the index elements' values (RFC
> 2578,
>              Section 3.5).
> 
> 
> *  Looking at the objects with TC of PortList (rbridgeMultiFibPorts,
> rbridgeSnoopingAddrPorts)
> 
> W: f(RBRIDGE-MIB.my), (921,20) Item "rbridgeMultiFibPorts" should have
> SIZE specified
> 
> 
>    rbridgeMultiFibPorts OBJECT-TYPE
>        SYNTAX      PortList
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>            "The list of ports to which a frame destined to this
>            multicast distribution tree is flooded. This may be pruned
>            further based on other forwarding information."
>        ::= { rbridgeMultiFibEntry 2 }
> 
> Q-BRIDGE-MIB defines:
> PortList ::= TEXTUAL-CONVENTION
>     STATUS      current
>     DESCRIPTION
>         "Each octet within this value specifies a set of eight
>         ports, with the first octet specifying ports 1 through
>         8, the second octet specifying ports 9 through 16, etc.
>         Within each octet, the most significant bit represents
>         the lowest numbered port, and the least significant bit
>         represents the highest numbered port.  Thus, each port
>         of the bridge is represented by a single bit within the
>         value of this object.  If that bit has a value of '1'
>         then that port is included in the set of ports; the port
>         is not included if its bit has a value of '0'."
>     SYNTAX      OCTET STRING
> 
> OCTET STRING is 0..65535 characters.
> 
> Consider that a range of 0..255 would give 8*256 == 2048 Ports
> Are more ports needed?
> 
> 
> 
> * Both compilers warn about rbridgeSnoopingEntry
> 
> The DESCRIPTION clause indicates that IPv4 and IPv6 so 4 or 16 byes,
so
> why
> is this
> not indicated?  (An example is below.)
> 
>    rbridgeSnoopingAddrType OBJECT-TYPE
>        SYNTAX      InetAddressType { unknown(0), ipv4(1), ipv6(2)}
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The IP multicast address type for which a listener has
been
>            detected by this RBridge. This MIB requires support for
only
>            IPv4 and IPv6 address types."
>        REFERENCE
>            "RFC 6325 section 4.7"
>        ::= { rbridgeSnoopingAddrEntry 1 }
> 
>    rbridgeSnoopingAddr OBJECT-TYPE
>        SYNTAX      InetAddress (SIZE(0|4|16))
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The IP multicast address for which a listener has been
>            detected by this RBridge. The address type of this object
>            is specified in rbridgeSnoopingAddrType. This MIB requires
>            support for only global IPv4 and IPv6 addresses, so the
>            length of the object can be either 4 or 16 bytes."
>        REFERENCE
>            "RFC 6325 section 4.7"
>        ::= { rbridgeSnoopingAddrEntry 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.
> 
> 
> INDEXING
> ========
> I am a little concerned about the Indexing in this MIB, only because
it
> looks like several table
> should really have an AUGMENTS relationship.
> 
>        INDEX  { rbridgeBaseNicknameName }
>        INDEX  { rbridgeBasePort }
>        INDEX   { rbridgeFdbId, rbridgeUniFdbAddr }
>        INDEX   { rbridgeUniFibNickname, rbridgeUniFibPort,
>        INDEX   { rbridgeMultiFibNickname }
>        INDEX   { rbridgeVlanIndex }
>        INDEX   { rbridgeBasePort, rbridgeVlanIndex }
>        INDEX   { rbridgeBasePort }
>        INDEX   { rbridgeVlanIndex }
>        INDEX   { rbridgeBasePort }
>        INDEX  { rbridgeVlanIndex, rbridgeSnoopingAddrType,
>        INDEX  { rbridgeDtreeNumber }
>        INDEX  { rbridgeTrillNbrMacAddr }
> 
> 
> 
> * Conformance Statement.
> Same comment as on the prior draft.  Still no read-only and full
> conformance.
> This is okay, but want to make sure that working group is "okay" with
> having
> to do a full conformance (i.e. support read-write and read-create via
> SNMP)?
> 
> 
> ----- Original Message -----
> From: "Bert Wijnen (IETF)" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <draft-ietf-trill-rbridge-
> [email-masked]>;
> <[email-masked]>
> Sent: Tuesday, April 10, 2012 4:53 AM
> Subject: Re: [MIB-DOCTORS] Help with conformance statements
> 
> 
> > From a quick read that I did (section 6.7), then it
> > indeed seems to specify a set of requirements (even in
> > MUST) language for the ISIS-MIB module. So here (in
> > sect 6.7) they are described in English.
> >
> > It would indeed be useful to have that documented
> > in machine readable format, i.e. in (or as part of)
> > a MODULE-COMPLIANCE statement.
> >
> > Is it a reason to hold up the document?
> > Not sure about that. At the time when I was AD, I
> > tried to strongly encourage people to express such
> > requirements in the form of MODULE_COMPLIANCE
> > statements. But that was/is my view.
> >
> > Maybe other MIB doctors do have an opinion on that.
> >
> > Bert
> >
> > On 4/8/12 10:34 PM, Adrian Farrel wrote:
> >> Hi,
> >>
> >> Is there a MIB Doctor that can help us?
> >>
> >> I am holding a Discuss on draft-ietf-trill-rbridge-mib-07.txt
> >>
> >> It reads...
> >>
> >>> 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).
> >>
> >> Can anyone tell me if I am right or wrong.
> >>
> >> Thanks,
> >> Adrian
> >>
> >>
> >> _______________________________________________
> >> MIB-DOCTORS mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mib-doctors
> >>
> > _______________________________________________
> > MIB-DOCTORS mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mib-doctors
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 2 Oct 2012 08:46:35 -0400

Dan,

I have not reviewed this draft, however a quick scan reveals that 3 comments 
made during
MIB Dr. review have not been addressed:

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

Will do a more thorough check on other MIB Dr. review comments later, but 
think these 3 are critical and should be
discussed/followed-up.

Thanks,
  -Joan

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>; "Bert Wijnen (IETF)" 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; "Ralph Droms" <[email-masked]>
Sent: Monday, October 01, 2012 5:06 AM
Subject: draft-ietf-trill-rbridge-mib-08 (was: RE: [MIB-DOCTORS] Help with 
conformance statements)

Hi Joan,

Thanks and Regards,

Dab

Not
via
to
have
restriction
so
been
only
it
to
two
or

---

From: Benoit Claise <[email-masked]>
Date: Wed, 03 Oct 2012 11:21:54 +0200

Hi Joan,

Thanks for your review.
Let me update the DISCUSS/COMMENT with your feedback below.
Do you know when you will have the time to review the MIB module?
Note that the authors posted a new version of the MIB module, addressing 
one DISCUSS point:

    The IETF datatracker page for this Internet-Draft is:
    https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-mib/

    Diff from previous version:
    http://www.ietf.org/rfcdiff?url2=draft-ietf-trill-rbridge-mib-09

Regards, Benoit.
> Dan,
>
> I have not reviewed this draft, however a quick scan reveals that 3 
> comments made during
> INDEX  { rbridgeBasePort } is used as an index in several tables and 
> the relationship
> and asked that the WG be informed that in order to be compliant with 
> the MIB,
> 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.
>
>
> Will do a more thorough check on other MIB Dr. review comments later, 
> but think these 3 are critical and should be
> discussed/followed-up.
>
> Thanks,
>  -Joan
>
>
> ----- Original Message ----- From: "Romascanu, Dan (Dan)" 
> <[email-masked]>
> Cc: <[email-masked]>; 
> <[email-masked]>; 
> Subject: draft-ietf-trill-rbridge-mib-08 (was: RE: [MIB-DOCTORS] Help 
> with conformance statements)
>
>
> Hi Joan,
>

---

From: "Joan Cucchiara" <[email-masked]>
Date: Thu, 4 Oct 2012 09:05:35 -0400

Benoit,

Thanks for the info about version 9.   I'll try to have a more thorough review done by Tues.

Thanks,
  -Joan

  ----- Original Message ----- 
  From: Benoit Claise 
  To: Joan Cucchiara 
  Cc: Romascanu, Dan (Dan) ; Bert Wijnen (IETF) ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; Ralph Droms 
  Sent: Wednesday, October 03, 2012 5:21 AM
  Subject: Re: [MIB-DOCTORS] draft-ietf-trill-rbridge-mib-08

  Hi Joan,

  Thanks for your review.
  Let me update the DISCUSS/COMMENT with your feedback below.
  Do you know when you will have the time to review the MIB module?
  Note that the authors posted a new version of the MIB module, addressing one DISCUSS point:

  Regards, Benoit.

    Dan, 

    I have not reviewed this draft, however a quick scan reveals that 3 comments made during 
    MIB Dr. review have not been addressed: 

    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) 

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

    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. 

    Will do a more thorough check on other MIB Dr. review comments later, but think these 3 are critical and should be 
    discussed/followed-up. 

    Thanks, 
     -Joan 

    ----- Original Message ----- From: "Romascanu, Dan (Dan)" <[email-masked]> 
    To: "Joan Cucchiara" <[email-masked]>; "Bert Wijnen (IETF)" <[email-masked]>; <[email-masked]> 
    Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; "Ralph Droms" <[email-masked]> 
    Sent: Monday, October 01, 2012 5:06 AM 
    Subject: draft-ietf-trill-rbridge-mib-08 (was: RE: [MIB-DOCTORS] Help with conformance statements) 

    Hi Joan, 

    Thanks and Regards, 

    Dab 

      -----Original Message----- 

      Adrian and Bert, 

    Not 

      a 

    via 

      SNMP. 

    to 

      the authors. 

      fyi, 
        -Joan 

      OUTPUT from SMICNGPRO 
      ----------------------- 

    have 

      SMILINT 
      ----------- 

    restriction 

      Q-BRIDGE-MIB defines: 

    so 

      why 
      is this 

    been 

    only 

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

      INDEXING 
      ======== 

    it 

      looks like several table 

      * Conformance Statement. 

      ----- Original Message ----- 
      From: "Bert Wijnen (IETF)" <[email-masked]> 
      To: <[email-masked]> 
      Cc: <[email-masked]>; <draft-ietf-trill-rbridge- 
      [email-masked]>; 
      <[email-masked]> 
      Sent: Tuesday, April 10, 2012 4:53 AM 
      Subject: Re: [MIB-DOCTORS] Help with conformance statements 

    to 

    two 

      Trill 

    or

---

From: "Joan Cucchiara" <[email-masked]>
Date: Wed, 10 Oct 2012 00:17:33 -0400

Hello,

The following is a review of version 9.   Many prior comments have been updated
and are reflected in this new draft, so Thank you for that. 

-Joan

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
mibs/RBRIDGE-MIB.my:1452: [5] {index-exceeds-too-large} warning: index of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 142 subidentifier(s)

Error:       index-element-no-size (level 3)
Message:     index element `%s' of row `%s' must have a size restriction
Description: Object identifiers are restricted in size to have at most 128
             sub-identifiers. This implies that index elements used to form
             instance identifiers must have a size contraint which ensures
             that the 128 sub-identifier constraint is kept intact for any
             possible combination of the index elements' values (RFC 2578,
             Section 3.5).

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

Unsigned32(0..3).

DEFVAL(0) <-- only version supported right now.

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

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

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

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

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

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

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

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

*) rbridgeBasePort
Where did you get the range for this Index?
I think you should define a TC for this Value.
This is used as an index for this table, and is used
in several other tables as an index, thus a TC would
be better.

*)I asked this in a prior review, but could you specify
the ifType associated with the ifIndex, i.e. physical
layer?

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

*) rbridgeBasePortStpRootChanges
Please remove UNITS clause.  The units is a count and
we know that already.

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

*) rbridgeConfidenceNative
Need to add DEFVAL (32)

*) rbridgeConfidenceDecap
Need to add DEFVAL (32)

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

*)rbridgeUniFdbPort DESCRIPTION clause
mentions rbridgeUniFdbAddress but I think the object is
rbridgeUniFdbAddr?

*)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?

*) rbridgeVlanIndex 
Why was VlanIndex from Q-BRIDGE-MIB not used?

*) rbridgeVlanForwarderLosts
Please remove the UNITS clause.

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

*) rbridgePortCounterEntry
Why is AUGMENTS not used here?
Using AUGMENTS is actually quite meaningful here and
I asked about this in a prior review.  Please clarify.
Additionally, the naming should be consistent with
the rbridgeBasePortTable (so rbridgeBasePortCounterTable) etc.

UNITS clauses for these counters can be removed.
The UNIT is a count, so kind of redundant.

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

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

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

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

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

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

*) rbridgeDtreeActiveTrees
Should this be a Gauge32?

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

*) rbridgeTrillMaxMtuProbes
Why does this value need to be saved after reinitializations?

*) 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?

Conformance and Group
---------------------

*) As mentioned prior, the Compliances and Groups are reversed order.

*) Also, as mentioned prior, this conformance does not have a read-only
version.  While not technically incorrect, most recent MIBs support
a Full Conformance and a Read-only Conformance.  
Have you confirmed with the WG that this is what they want and
if they will implement this MIB as written?

--- end of review ------

---

From: Anil R <[email-masked]>
Date: Wed, 10 Oct 2012 08:18:59 -0400

Joan,

Sorry, you don't get multiple cracks at making yet another round of comments on the same document. As you have noted below, most of your prior comments have been addressed. We have to draw a line somewhere.

This MIB has been held up for a year in IESG review! This has been primarily due to your multiple rounds of "exhaustive reviews", most of which have been nits or subjective opinions. Every time a new draft has been published to address the previous round of comments, you have come right back with a new round of comments. This is unprecedented in my long experience of writing IETF MIBs.

Versions -04 to -09 have been written to address IESG (mostly your) comments. That is fully 60% of the drafts written.

If you have so many comments, you should have been done so as part of the TRILL working group. This is an IETF working group, and most of the work is done in the IETF - not in the IESG. Please don't try to influence or delay work from outside of a working group.

I have contacted both the Internet AD and Operations AD. This non-stop barrage of mib-doctor nits, apparently to prevent a document from moving forward, is unacceptable to me and the working group, and should be unacceptable to the IESG. We need to get this document published now.

Thanks,
Anil

---

From: Benoit Claise <[email-masked]>
Date: Wed, 10 Oct 2012 15:35:17 +0200

Anil,

Please direct your message to me, as I'm the one owning the COMMENT.  
However, it's a good practice to copy mib-doctors.
Also please use the list from my COMMENT, as there are a couple that I 
didn't insist on (like the UNITS clause for example), and because I 
regrouped them.
Reminder: the MIB doctor is not part of the IESG, but provide feedback 
to the IESG.
" We need to get this document published now". Agreed, but not at all costs.

Can we please go back in the mood of progressing the draft!

Regards, Benoit.
> Joan,
>
> Sorry, you don't get multiple cracks at making yet another round of 
> comments on the same document. As you have noted below, most of your 
> prior comments have been addressed. We have to draw a line somewhere.
>
> This MIB has been held up for a year in IESG review! This has been 
> primarily due to your multiple rounds of "exhaustive reviews", most of 
> which have been nits or subjective opinions. Every time a new draft 
> has been published to address the previous round of comments, you have 
> come right back with a new round of comments. This is unprecedented in 
> my long experience of writing IETF MIBs.
>
> Versions -04 to -09 have been written to address IESG (mostly your) 
> comments. That is fully 60% of the drafts written.
>
> If you have so many comments, you should have been done so as part of 
> the TRILL working group. This is an IETF working group, and most of 
> the work is done in the IETF - not in the IESG. Please don't try to 
> influence or delay work from outside of a working group.
>
> I have contacted both the Internet AD and Operations AD. This non-stop 
> barrage of mib-doctor nits, apparently to prevent a document from 
> moving forward, is unacceptable to me and the working group, and 
> should be unacceptable to the IESG. We need to get this document 
> published now.
>
> Thanks,
> Anil
>
>
>> W: f(RBRIDGE-MIB.my), (47,17) The first revision should match the 
>> last update for MODULE-IDENTITY rbridgeMIB
>> W: f(RBRIDGE-MIB.my), (1452,4) Row "rbridgeSnoopingAddrEntry" has 
>> W: f(RBRIDGE-MIB.my), (1043,18) Row "rbridgeVlanPortEntry" does not 
>> have a consistent indexing scheme - cannot specify an index item from 
>> mibs/RBRIDGE-MIB.my:1452: [5] {index-exceeds-too-large} warning: 
>> index of row `rbridgeSnoopingAddrEntry' can exceed OID size limit by 
>> 142 subidentifier(s)

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Oct 2012 10:36:55 -0400

Anil - as Benoit wrote, please refer to the list of Comments in the IESG Evaluation Record, which Benoit extracted from Joan's careful and helpful review.

I see two issues: the length of time that the review has taken, and the importance and validity of the comments on the document.  The review has taken a long time for a variety of reasons and it's inappropriate to assign blame to any individual.  It is especially inappropriate to assign a motivation to what you perceive as an unnecessarily long review process.

We have a list of comments from Benoit in his AD review.  Let's work to resolve those comments so the document can be published.

- Ralph