[MIB-DOCTORS] MIB doctor review for draft-ietf-bfd-tc-mib-07.txt

"Bert Wijnen (IETF)" <bertietf@bwijnen.net> Thu, 08 May 2014 12:26 UTC

Return-Path: <bertietf@bwijnen.net>
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CE91A03DC for <mib-doctors@ietfa.amsl.com>; Thu, 8 May 2014 05:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7G44ghCW6i7 for <mib-doctors@ietfa.amsl.com>; Thu, 8 May 2014 05:26:41 -0700 (PDT)
Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 712641A04AF for <mib-doctors@ietf.org>; Thu, 8 May 2014 05:26:41 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1WiNPE-0007mA-Mb; Thu, 08 May 2014 14:26:34 +0200
Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest48.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from <bertietf@bwijnen.net>) id 1WiNPE-0001p6-I2; Thu, 08 May 2014 14:26:32 +0200
Message-ID: <536B77F8.8050407@bwijnen.net>
Date: Thu, 08 May 2014 14:26:32 +0200
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: draft-ietf-bfd-tc-mib.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40ccdb30915175a299f26062f5ebcb791
Archived-At: http://mailarchive.ietf.org/arch/msg/mib-doctors/NoTJs1aKq6LjA3lf_tXlJIISQso
Cc: "mib-doctors >> MIB Doctors" <mib-doctors@ietf.org>
Subject: [MIB-DOCTORS] MIB doctor review for draft-ietf-bfd-tc-mib-07.txt
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mib-doctors/>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 May 2014 12:26:43 -0000

Sorry for my late review. Vacation and blabla-excuses.
Hope this is still helpful.

1.I can live with (i.e. this is just a comment, not a blocking issue) TCs for
       BfdCtrlDestPortNumberTC
       BfdCtrlSourcePortNumberTC
   But I fail to see why InetPortNumber TC would not suffice.

2.The same is more or less true for

     BfdSessIndexTC ::= TEXTUAL-CONVENTION
     DISPLAY-HINT   "d"
     STATUS         current
     DESCRIPTION
         "An index used to uniquely identify BFD sessions."
     SYNTAX Unsigned32 (1..4294967295)

   If you see it used in, for example:
     bfdSessDiscMapIndex OBJECT-TYPE
         SYNTAX     BfdSessIndexTC
         MAX-ACCESS read-only
         STATUS     current
         DESCRIPTION
             "This object specifies a mapping between a
              local discriminator and a BFD Session in
              the BfdSessTable."
         ::= { bfdSessDiscMapEntry 1 }

   Then I wonder what value the TC adds?

3.Same for:
     BfdIntervalTC ::= TEXTUAL-CONVENTION
     DISPLAY-HINT  "d"
     STATUS        current
     DESCRIPTION
         "The BFD interval in microseconds."
     SYNTAX Unsigned32 (0..4294967295)


   If you see it used in, for example

     bfdSessDesiredMinTxInterval OBJECT-TYPE
         SYNTAX     BfdIntervalTC
         MAX-ACCESS read-create
         STATUS     current
         DESCRIPTION
             "This object specifies the minimum interval, in
              microseconds, that the local system would like to use
              when transmitting BFD Control packets. The value of
              zero(0) is reserved in this case, and should not be
              used."
         REFERENCE
             "Section 4.1 from Katz, D. and D. Ward, Bidirectional
              Forwarding Detection (BFD), RFC 5880, June 2012."
         ::= { bfdSessEntry 25 }

    Then what value is added by using a TC. In fact you can even quetion if it
    is not conflicting, because according to the TC description clause I would
    expect zero to be a valid interval value, where as here it describes
    that zero is a special value and should not be used. So it is only special
    Since it should NOT BE used, or does zero mean something special?
    Assuming zero SHOULD NOT be used. I personally would just do:

     bfdSessDesiredMinTxInterval OBJECT-TYPE
         SYNTAX Unsigned32 (1..4294967295)
         MAX-ACCESS read-create
         STATUS     current
         UNITS      microseconds
         DESCRIPTION
             "This object specifies the minimum interval that the local
              system would like to use when transmitting BFD Control packets.
         REFERENCE
             "Section 4.1 from Katz, D. and D. Ward, Bidirectional
              Forwarding Detection (BFD), RFC 5880, June 2012."
         ::= { bfdSessEntry 25 }

   In case zero has special meaning I would do:
     bfdSessDesiredMinTxInterval OBJECT-TYPE
         SYNTAX Unsigned32 (0 | 1..4294967295)
         MAX-ACCESS read-create
         STATUS     current
         UNITS      microseconds
         DESCRIPTION
             "This object specifies the minimum interval that the local
              system would like to use when transmitting BFD Control packets.
              The value zero has been reserved for a special maning:
              <describe what zero means>
         REFERENCE
             "Section 4.1 from Katz, D. and D. Ward, Bidirectional
              Forwarding Detection (BFD), RFC 5880, June 2012."
         ::= { bfdSessEntry 25 }

  4. Same for
     BfdMultiplierTC ::= TEXTUAL-CONVENTION
     DISPLAY-HINT    "d"
     STATUS          current
     DESCRIPTION
         "The BFD failure detection multiplier."
     SYNTAX Unsigned32 (1..255)

     Again, what value does the use of a TC add here?

It boils down to the question: does the BFD-TC-STD-MIB make sense at all or is it
just extra/superfluous text? was the concept of TC invented for that?

The IANA-BFD-TC-STD-MIB module makes sense I think, because it allows to add
definitions by the IANA function.

I have not yet done a MIB SYNTAX checker run on it. But I assume others have done so.
Bert

Bert