[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Discuss on draft-ietf-iptel-trip-mib-08.txt
- To: iesg@ietf.org
- Subject: Discuss on draft-ietf-iptel-trip-mib-08.txt
- From: Margaret Wasserman <mrw@windriver.com>
- Date: Wed, 17 Sep 2003 22:55:20 -0400
I have posted a discuss on this draft with the attached
comments (very long, sorry).
Margaret
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.