[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [sip] I-D ACTION:draft-ietf-sip-mib-08, changes since draft07
Bob and other,
As I have said in the meeting, I am not a big fan for having semantics inserted in applName - I believe that this would cause interoperability problems. It looks to me that adding ifIndex as a second index is a cleaner solution, although somehow more complex. To add to the complexity, I believe that if multiple SIP instances of the same application need to be modeled by separate interfaces than this should be documented by one more mapping table indexed by ifIndex to fully detail the 'SIP ports' mapping relationship.
Regards,
Dan
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org]On
> Behalf Of Bob Penfield
> Sent: 05 August, 2004 10:17 PM
> To: Jean-Francois Mule; sip at ietf.org
> Cc: klingle at cisco.com
> Subject: Re: [sip] I-D ACTION:draft-ietf-sip-mib-08, changes
> since draft07
>
>
>
> 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
>
_______________________________________________
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