Skip to main content

Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management
draft-ietf-bfd-tc-mib-08

Yes

(Adrian Farrel)

No Objection

(Alissa Cooper)
(Barry Leiba)
(Brian Haberman)
(Jari Arkko)
(Kathleen Moriarty)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
(Stephen Farrell)

Note: This ballot was opened for revision 07 and is now closed.

Adrian Farrel Former IESG member
Yes
Yes (for -07) Unknown

                            
Alia Atlas Former IESG member
Yes
Yes (2014-05-27) Unknown
The description for BfdCtrlSourcePortNumberTC lacks what the port is expected
to be though leaving the range open is described the same as for the BfdCtrlDestPortNumberTC.
This looks like a bit of copy-and-paste.   I'd assume that the source port can be anything in the
range referenced (i.e.  "Port 49152..65535 from RFC5881") and the description text should be
clarified/updated.
Alissa Cooper Former IESG member
No Objection
No Objection () Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection () Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2014-05-28) Unknown
Not really a blocking factor (DISCUSS), but it would nice if the situation would be clarified. 
As mentioned by Bert Wijnen, part of the MIB doctors review:

   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 question 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 }

BENOIT: the alternative is to have the following TC and to simplify the defintion
   BfdIntervalTC ::= TEXTUAL-CONVENTION
    DISPLAY-HINT  "d"
    STATUS        current
    DESCRIPTION
        "The BFD interval in microseconds."
    SYNTAX Unsigned32 (1..4294967295)



   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 meaning:
             <describe what zero means>
        REFERENCE
            "Section 4.1 from Katz, D. and D. Ward, Bidirectional
             Forwarding Detection (BFD), RFC 5880, June 2012."
        ::= { bfdSessEntry 25 }
Brian Haberman Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2014-05-24) Unknown
looks like mib doctors et al have no discussion going on that will result in changes.
Kathleen Moriarty Former IESG member
No Objection
No Objection () Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection () Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection () Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection () Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection () Unknown