Management Information Base for Telephony Routing over IP (TRIP)
draft-ietf-iptel-trip-mib-10

[Ballot comment]
If the WG is respinning another rev (based on other IESG member discuss points), then pls also consider:
- tripCfgProtocolVersion
  has a REFERENCE clause talking about RFC 3291.
  I think they mean RFC3219 instead.
- tripNotifApplIndex
  has text in DESCRIPTION clause talking about RFC2788.
  probably better to add a REFERENCE clause to point to RFC2788
- The object tripCfgStorage has as DESCRITPION clause:
        DESCRIPTION
          "The storage type for this conceptual row."
  According to RFC2579, one MUST specify which columns must be writable
  when the value is permanent. So if none have to be writable in that
  case, then one can do with:
        DESCRIPTION
          "The storage type for this conceptual row.

            Conceptual rows having the value 'permanent' need not allow
            write-access to any columnar objects in the row."

[Ballot discuss]
I have both substantive and editorial comments on this MIB.  The
substantive comments are the subject of my DISCUSS, and the
editorial comments are merely suggestions for things that should
be fixed if/when the draft is updated.

SUBSTANTIVE COMMENTS:

    TripAddressFamily ::= TEXTUAL-CONVENTION

        SYNTAX INTEGER { decimal(1), pentadecimal(2), e164(3) }

    TripAppProtocol ::= TEXTUAL-CONVENTION

        SYNTAX INTEGER { sip(1), q931(2), ras(3), annexG(4) }

>> Is there a reason not to include an "other(x)" option in the two
>> enumerations above?  An "other(x) option might be useful in the
>> future, if additional application protocols or address families are
>> defined.  Although the MIB should be updated in that case, there
>> may be a lag between when new values are defined and when the
>> MIB is updated.  An "other(x)" enumeration would be useful
>> during that transition period.

    tripCfgAddr OBJECT-TYPE
        SYNTAX      InetAddress
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The network address of the local LS that the peer c
            onnects to. The type of address depends on the object
            tripCfgAddrIAddrType."

>> Is there a trip protocol restriction that all instance of
>> TRIP that run on a single box must be reached at the same
>> IP address?  If not, then this variable (and its associated
>> type) should probably move to one of the tables.

    tripPeerState OBJECT-TYPE
        SYNTAX      INTEGER {
                        idle(1),
                        connect(2),
                        active(3),
                        openSent(4),
                        openConfirm(5),
                        established(6)
                    }

>> Are there really no error or closing states possible for
>> the connection to the peer? 

tripRoutePeer OBJECT-TYPE
        SYNTAX      TripId
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "The identifier of the peer where the route information
            was learned."
        ::= { tripRouteEntry 4 }

>> Why is this object used to identify a peer in the tripRouteTable,
>> but the tripPeerTable uses:
>>        INDEX { applIndex,
>>              tripPeerRemoteAddrInetType,
>>              tripPeerRemoteAddr,
>>              tripPeerRemotePort }
>> as an INDEX?

>> How is one expected to locate the correct tripPeerTable entry for
>> the peer identified in the tripRouteTable?  Is this something that
>> we expect that people will want to do regularly?
>>
>> I am having some trouble understanding the relationship between
>> the different tables in this MIB, perhaps because there is no
>> text describing those relationships.  My current understanding
>> is that we have one or more trip application instances, and there
>> is a set of configuration and state information associated with
>> each application instance.  Each application instance may have
>> several peers, and there is a set of configuration and state
>> information associated with each peer.  Each peer may have several
>> routes, and there is configuration and state information associated
>> with each route.  Is that about right?
>>
>> If so, how do I efficiently find the routes associated with each
>> peer?

  [RFC1657] Willis, S., Burruss, J., and Chu, J., "Definitions of
            Managed Objects for the Fourth Version of the Border
              Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July
              1994.

>> This should not be a normative reference.  If this text started
>> with text from the BGP MIB, it is okay to give credit.  But
>> it should not be required to read the BGP MIB in order to
>> understand this MIB.

EDITORIAL COMMENTS:

Abstract

  This memo defines a portion of the MIB (Management Information Base)
  module for use with network management protocols in the Internet
  community. In particular, it describes a set of managed objects that
  are used to manage for TRIP (Telephony Routing over IP) devices.

>> s/used to manage for TRIP/used to manage TRIP/

  The TRIP MIB module contains the following groups of objects:
  o The tripConfigGroup contains the common configuration objects
    applicable to all TRIP applications referenced by the applIndex.
  [...]

>> Much more text would be helpful that describes the purpose of
>> the tables within this MIB and their relationship to each
>> other.  This list seems only to list the compliance groups,
>> without giving any real insight into the structure of the
>> MIB.

>> The word "referenced" is misspelled "referened" in a couple
>> of places.

>> It would be more helpful to define acronyms (TRIB, ITAD...) when
>> they are first used, instead of later.

    tripCfgAddr OBJECT-TYPE
        SYNTAX      InetAddress
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The network address of the local LS that the peer c
            onnects to. The type of address depends on the object
            tripCfgAddrIAddrType."

>> Formatting error in first line of description.
>>
>> Also, is it acceptable for this address to be a DNS name?  If
>> not, then that restriction should be included in the
>> description.

    tripCfgOperStatus OBJECT-TYPE
        SYNTAX      INTEGER {
                        up(1),
                        down(2),
                        faulty(3)
                    }
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The current operational state of the TRIP protocol.

            up(1):    The application is operating normally, and
                        is processing (receiving and possibly
                        issuing) TRIP requests and responses.

            down(2):  The application is currently not processing
                        TRIP messages. This occurs if the TRIP
                        application is in an initialization state or
                        if tripCfgAdminStatus is set to down(2).

            faulty(3): The application is not operating normally due
                        to a fault in the system.

            If tripCfgAdminStatus is down(2) then tripOperStatus SHOULD
            be down(2). If tripAdminStatus is changed to up(1) then
            tripOperStatus SHOULD change to up(1) if there is no
            fault that prevents the TRIP protocol from moving to the
            up(1) state."
        ::= { tripCfgEntry 5 }

>> It should be made clearer that these objects only reflect the
>> state of the application layer, not the whole system.  For
>> instance, an "up" status doesn't actually indicate that
>> TRIP messages are being sent/received, only that the application
>> layer is in a status where it is ready to send/receive them.

>> There doesn't seem to be a way to specify read-only compliance.
>> Is it intended to require that all TRIP MIB implementations are
>> read-write?

[Ballot comment]
If the WG is respinning another rev (based on other IESG member discuss points), then pls also consider:
- tripCfgProtocolVersion
  has a REFERENCE clause talking about RFC 3291.
  I think they mean RFC3219 instead.
- tripNotifApplIndex
  has text in DESCRIPTION clause talking about RFC2788.
  probably better to add a REFERENCE clause to point to RFC2788

[Ballot comment]
If the WG is respinning another rev (based on other IESG member discuss points), then pls also consider:
- draft-ietf-mpls-te-mib-12.txt
  has a REFERENCE clause talking about RFC 3291.
  I think they mean RFC3219 instead.
- tripNotifApplIndex
  has text in DESCRIPTION clause talking about RFC2788.
  probably better to add a REFERENCE clause to point to RFC2788

[Ballot comment]
To Ned: I would imagine it will be some time before this goes to Draft. ;)

To Margaret: I think some changes are certainly warranted based on your comments - I'll take these back to the authors. On a few of the points, the TRIP MIB draft merely copies RFC1657, for better or for worse (perhaps for worse), just as TRIP copies from BGP.

[Ballot discuss]
I have both substantive and editorial comments on this MIB.  The
substantive comments are the subject of my DISCUSS, and the
editorial comments are merely suggestions for things that should
be fixed if/when the draft is updated.

SUBSTANTIVE COMMENTS:

  The TRIP MIB module contains the following groups of objects:
  o The tripConfigGroup contains the common configuration objects
    applicable to all TRIP applications referenced by the applIndex.
  [...]

>> Much more text would be helpful that describes the purpose of
>> the tables within this MIB and their relationship to each
>> other.  This list seems only to list the compliance groups,
>> without giving any real insight into the structure of the
>> MIB.

    TripAddressFamily ::= TEXTUAL-CONVENTION
        STATUS current
        DESCRIPTION
            "A type of address for a TRIP route. Address families
            defined within this MIB module are:

            Code              Address Family
            1                Decimal Routing Numbers
            2                PentaDecimal Routing Numbers
            3                E.164 Numbers"

        SYNTAX INTEGER { decimal(1), pentadecimal(2), e164(3) }

    TripAppProtocol ::= TEXTUAL-CONVENTION
        STATUS current
        DESCRIPTION
            "The application protocol used for communication with TRIP
            Location Servers. Protocols defined in this MIB Module
            are:

            Code              Protocol
            1                SIP
            2                H.323-H.225.0-Q.931
            3                H.323-H.225.0-RAS
            4                H.323-H.225.0-Annex-G"

        SYNTAX INTEGER { sip(1), q931(2), ras(3), annexG(4) }

>> Is there a reason not to include an "other(x)" option in the two
>> enumerations above?  An "other(x) option might be useful in the
>> future, if additional application protocols or address families are
>> defined.

    tripCfgAdminStatus OBJECT-TYPE
        SYNTAX      INTEGER {
                        up(1),
                        down(2)
                    }
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
            "The desired TRIP state.

            up(1)  : Set the application to normal operation.

            down(2): Set the application to a state where it will
                      not process TRIP messages."
        ::= { tripCfgEntry 4 }

    tripCfgOperStatus OBJECT-TYPE
        SYNTAX      INTEGER {
                        up(1),
                        down(2),
                        faulty(3)
                    }
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The current operational state of the TRIP protocol.

            up(1):    The application is operating normally, and
                        is processing (receiving and possibly
                        issuing) TRIP requests and responses.

            down(2):  The application is currently not processing
                        TRIP messages. This occurs if the TRIP
                        application is in an initialization state or
                        if tripCfgAdminStatus is set to down(2).

            faulty(3): The application is not operating normally due
                        to a fault in the system.

            If tripCfgAdminStatus is down(2) then tripOperStatus SHOULD
            be down(2). If tripAdminStatus is changed to up(1) then
            tripOperStatus SHOULD change to up(1) if there is no
            fault that prevents the TRIP protocol from moving to the
            up(1) state."
        ::= { tripCfgEntry 5 }

>> These objects might also benefit from an "other(x)" and/or
>> "unknown(x)" option.  Also, are you expecting these objects to
>> reflect the state of the whole system, or only of the TRIP
>> application.  For instance, if TRIP is running properly and ready
>> to service messages, but the IP stack has (temporarily or
>> permanently) lost its network connectivity, would you expect the
>> tripOperStatus to be up or down?

    tripCfgAddr OBJECT-TYPE
        SYNTAX      InetAddress
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The network address of the local LS that the peer c
            onnects to. The type of address depends on the object
            tripCfgAddrIAddrType."

>> Is there a trip protocol restriction that all instance of
>> TRIP that run on a single box must be reached at the same
>> IP address?  If not, then this variable (and its associated
>> type) should probably move to the tripRouteTypeTable).

    tripPeerState OBJECT-TYPE
        SYNTAX      INTEGER {
                        idle(1),
                        connect(2),
                        active(3),
                        openSent(4),
                        openConfirm(5),
                        established(6)
                    }

>> Are there really no error or closing states possible for
>> the connection to the peer? 

tripRoutePeer OBJECT-TYPE
        SYNTAX      TripId
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
            "The identifier of the peer where the route information
            was learned."
        ::= { tripRouteEntry 4 }

>> Why is this object used to identify a peer in the tripRouteTable,
>> but the tripPeerTable uses:
>>        INDEX { applIndex,
>>              tripPeerRemoteAddrInetType,
>>              tripPeerRemoteAddr,
>>              tripPeerRemotePort }
>> as an INDEX?

>> How is one expected to locate the correct tripPeerTable entry for
>> the peer identified in the tripRouteTable?  Why not just use the
>> tripPeerIdentifier to reference the tripPeerTable?

>> There doesn't seem to be a way to specify read-only compliance.
>> Is it intended to require that all TRIP MIB implementations are
>> read-write?

EDITORIAL COMMENTS:

Abstract

  This memo defines a portion of the MIB (Management Information Base)
  module for use with network management protocols in the Internet
  community. In particular, it describes a set of managed objects that
  are used to manage for TRIP (Telephony Routing over IP) devices.

>> s/used to manage for TRIP/used to manage TRIP/

>> The word "referenced" is misspelled "referened" in a couple
>> of places.

>> It would be more helpful to define acronyms (TRIB, ITAD...) when
>> they are first used, instead of later.

    tripCfgAddr OBJECT-TYPE
        SYNTAX      InetAddress
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The network address of the local LS that the peer c
            onnects to. The type of address depends on the object
            tripCfgAddrIAddrType."

>> Formatting error in first line of description.
>>
>> Also, is it acceptable for this address to be a DNS name?  If
>> not, then that restriction should be included in the
>> description.

  [RFC1657] Willis, S., Burruss, J., and Chu, J., "Definitions of
            Managed Objects for the Fourth Version of the Border
              Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July
              1994.

>> Why is this a normative reference?  I don't think it should be
>> required to understand the BGP MIB in order to read this MIB.

[Ballot comment]
General question: Is the use of RFC 2788 here (and probably elsewhere) going to
mean it needs to advance to draft at some point?

State Changes to New Version Needed (WG/Author)                    from Expert Review                                    by sob

State Changes to Expert Review                                    from AD Evaluation                                    by sob

State Changes to AD Evaluation                                    from Dead                                              by scoya

State Changes to Dead                                              from Approved                                          by scoya

State Changes to Expert Review                                    from Pre AD Evaluation                                by Scott Bradner

State Changes to Pre AD Evaluation                                from AD Evaluation                                    by Scott Bradner

State Changes to AD Evaluation                                    from Approved                                          by Scott Bradner