Subject: [Sip] Review of draft-ietf-sip-mib-03.txt Part 2

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 11 Oct 2001 18:41:42 -0400

Further comments
================
SIP-COMMON-MIB (cont'd)

A further remark on sipInviteTimeout: in principle we need an
application-level timeout value for each method, not just INVITE.  We might
possibly get away with one for initial INVITE and one for all other
requests.  Clearly the expected turnaround for a REGISTER will be different
from that for a PRACK, but both of them should finish in a few seconds at
most rather than the minutes an initial INVITE could take.  I will again
question whether application-level timers belong in SIP-COMMON-MIB or in
SIP-UA-MIB.

sipMethodStatsEntry: INFO method should be treated like all other
extensions, rather than appear explicitly in this table.

sipSummaryTotalTransactions: description should indicate what a transaction
stateless proxy does with this counter (probably leaves it at 0).

sipStatsInfoIns, Outs: shouldn't be given special treatment -- belong in the
sipStatsExtMethodTable with all the other method extensions.

SipStatusCodesEntry: should "other" class entries be defined, for status
codes 700 and up?

sipStatsRedirClassIns, Outs: 3xx responses don't necessarily come from
Redirect Servers -- UAs could be set up to forward calls, for instance.
Hence the phrase "taken by a Redirect Server" in the description is
inappropriate.

sipStatsServerFailClassIns, Outs: final sentence of description defines SIP
protocol behaviour, not SNMP Agent behaviour, hence should be omitted.

sipStatsGlobalFailClassIns, Outs: ditto

sipStatsExtMethodStatus: description is a bit sparse.  Would something more
along the lines of the description for sipCommonStatusCodeStatus not be
desirable here too?

sipStatusCodeNotifTo, From, CallId, CSeq: do the reported values include the
header keywords themselves, or only the part following the colon? (e.g.)
"From:xx..x" vs. "xx..x"

sipCurrentTransTable: need something be said about transaction stateless
proxies?

sipCurrentTransEntry: typo in description -- should be "entity's" rather
than "entities'".  

SipTransactionEntry: need an object identifying the method which initiated
the transaction.

sipTransTo, From, CallId, CSeq: do the reported values include the header
keywords themselves, or only the part following the colon? (e.g.)
"From:xx..x" vs. "xx..x"

sipTransState: most of these states apply only to INVITE transactions, and
some of them (null, completed, confirmed) do not apply to transactions
currently in process.  I would suggest instead capturing the latest activity
in the transaction.  This has two parts: direction (received/sent) and
status code value or request (the latter being either the initiating request
or ACK).

sipTransExpiry: behaviour will be affected by the outcome of my initial
remark on sipInviteTimeout.

sipTransCallingPartyContentType, sipTransCalledPartyContentType: nice try,
but it doesn't work.  Content type varies from message to message within a
transaction.  Perhaps these objects could record the aggregation of content
types over all messages so far passed in the transaction -- that would
reflect your intent.
  
SipCommonStatsRetryEntry: as with sipMethodStatsEntry, the INFO method
should be treated like all other extensions, rather than appear explicitly
in this table.

sipOtherStatsEntry: typo in description -- should be "entity's" rather than
"entities'".

sipNotifApplIndex: doesn't point to the actual status code being monitored.
Shouldn't it be the same structure as the index of sipCommonStatusCodeTable?

SIP-UA-MIB
==========

General comment on configuration: should there be a requirement to populate
the SIP-COMMON-MIB data for each entity before populating this MIB?  How is
this expressed?

sipUAMIBNotifs is empty.

Where is the definition of sipUAStats??

sipUACfgSipServerEntry: should say that applIndex for each entity instance
has the same value as used for that instance in the tables of
SIP-COMMON-MIB.

Might it be desirable to configure the UA's Contact address?

SIP-SERVER-MIB
==============

General comment on configuration: should there be a requirement to populate
the SIP-COMMON-MIB data for each entity before populating this MIB?  How is
this expressed?

sipServerMIB: description has definitions of the different server types.
Would it be safer to refer to the RFC instead?  In any event, a Proxy does
not initiate requests (as indicated in the definition of a Redirect Server).
It does propagate them.

sipServerCfgEntry: should say that applIndex for each instance has the same
value as in SIP-COMMON-MIB.  Question: should there be a RowStatus object?
Can values be changed on the fly?

SipProxyCfgEntry: should there be a RowStatus object?

SipRegCfgEntry: ditto

sipContactPreference: typed as an OCTET STRING.  Couldn't that be an
IA5String, or is that not allowed in SNMP?

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)