Re: [sip] I-D ACTION:draft-ietf-sip-mib-08, changes since draft07

["Bob Penfield" <bpenfield at acmepacket.com>]

Items #5 and #80 from your response (excerpted below) got me thinking about
what an application is in SNMP terms and how it relates to multiple SIP
application instances of the same type. If I want to have separate stats
tables for each interface (SipPort), then each one would need to have a
different applIndex, and thus would have a separate entry in the applTable.
However, given the restrictions on the applName string, these would all have
the same applName. Is that legal? RFC 2788 seems to imply that it is not. If
so, should there be some text indicating that it is? or does there need to
be a suffix in the applName to disambiguate them?

Our customers are asking for SIP Statistics on a per interface (or per
domain) basis and we would like to use the SIP MIB.


cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield at acmepacket.com

----- Original Message ----- 
From: "Jean-Francois Mule" <jf.mule at cablelabs.com>
<snip>
------------------------------------------------------
5) Many proxies can control more than one domain at the same time.
   Need to support this.

AI: none
# Kevin and Cullen exchanged some emails on this topic:
# klingle: how might this manifiest itself in the mib?   additional
# indexing of the tables for domain?   what info about each domain
# might need to be cast into objects (ie, contents for a "domain
# table"). What about non-server entities?
#
# after more discussions, Cullen stated:
#  "we won't try to solve this one at this point."

<snip>
------------------------------------------------------
80)   1. Lack of "Interface" concept.

SIP MIB doesn't use a concept of a physical or logical
"interface" -  ifIndex (see RFC 2863 and draft-ietf-entmib-v3).
I think it is a big conceptual flaw because a typical network
application (which a normal SIP device is) has a concept of multiple
network interfaces either directly mapped to physical interfaces or
being logically defined for numerous application reasons.

AI: none
# The authors exchanged a series of emails with Orit at the end of
# March 2004. Below is a summary of our responses.
# In ITU-T, H.341 MIB for H.323 took the route of ifIndex first in the
# early days and they changed to applIndex. This was the motivation
# for the SIP mib to go with ifIndex. Since then, the TRIP mib was
# also drafted with applIndex
# http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-10.txt
# TRIP MIB draft 10 has passed IETF Last Call and is in the RFC ed
# queue. We think we are consistent with the use of the RFC2788 mib.

# Orit is ok with our explanation and trust the mib doctor would raise
# this as an issue. Comment closed

Usually most of the information for configuration, management and
monitoring needs to be defined per "interface". The most obvious
examples include: timers, retry counters and security parameters.

If a certain implementation doesn't have a concept of interface
 - a single "dummy" interface can be used across all MIB
 definitions for this simple device.

Note that the concept of "application" and the concept of
 "interface" are orthogonal - in many network devices
both are used.sipProxyAuthMethod

I suggest adding "ifIndex" as the second index
after "applIndex" at least to the following tables:
sipPortTable
sipExtMethodSupportedTable
sipCommonCfgTimerTable
sipCommonCfgTimerExtMethodTable
sipCommonCfgRetryTable
sipCommonCfgExpiresMethodTable
sipCommonCfgExpiresStatusCodeTable
sipUACfgSipServerTable





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip