Subject: [MIB-DOCTORS] Help with conformance statements

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 8 Apr 2012 21:34:48 +0100

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

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 10 Apr 2012 10:53:15 +0200

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:
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 10 Apr 2012 14:35:22 -0400

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]>; <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, April 10, 2012 4:53 AM
Subject: Re: [MIB-DOCTORS] Help with conformance statements