Subject: [SIP] Some brief comments on the SIP MIB

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 25 Oct 2000 22:10:04 -0400

- The Hide configuration options are redundant; obviously, they are in
RFC 2543, but I don't think it's useful to carry them forward.

- All systems need to understand compact form, so I'm not sure why this
is a variable.

- ULS should probably at least mention LDAP as an example.

- Supported URIs should probably say URI "schemes" rather than just
URIs, as the current text can be read to imply to list all user SIP URIs
managed by the server.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Kevin Lingle <[email-masked]>
Date: Fri, 27 Oct 2000 12:02:32 -0400

Henning,

Thanks for the comments.  I presume they are based on the
draft-ietf-sip-mib-01.txt version of the I-D.

> RFC 2543, but I don't think it's useful to carry them forward.

There are a couple of objects (in two different mib modules) that speak
about hiding.  

SIP-COMMON-MIB... sipHideOperation - clearly references rfc 2543.
SIP-SERVER-MIB... sipHideRespect.

Are you suggesting we drop both of these objects?

> - All systems need to understand compact form, so I'm not sure why this

I'll consider this object dropped in the next revision of the draft.

> - ULS should probably at least mention LDAP as an example.

ULS has undergone some changes.  We had a request to handle prioritzed
backup addressess.  I also got some comments that having one generic
ULS address wasn't sufficient.  Systems may have multiple resources they
use to determine where users are.

You can view the proposal on [email-masked] archive
[http://www.egroups.com/message/sip-mib/40].  There has been no
feedback on the proposal yet (unfortunately that is typical).
I would appreciate if you could take a quick look.  Btw, the
current proposal does not actualy handle prioritized addresses
correctly (i need to consider that further).  What is your view
on having the ability to specify backup addresses ULS?

Wrt your specific comment on LDAP as it might relate to the new
proposal for ULS objects... (see proposal to understand the objects)
One way to handle LDAP would be to have sipULSAddrSipEntity set to
'other' because LDAP is not a true sip entity and use the
sipULSAddrSipEntityDescr object (a free form string description of
the addressed entity) to reflect it's an address for a LDAP server.

Actually, as I think about it, the names and semantics of some of
these newly proposed object aren't a great fit for addressing non-sip
entities.   Maybe we need a 'nonSip' enumeration for the SipEntityType
textual convention (specifies the range of values for sipULSAddrSipEntity
object. And maybe the sipULSAddrSipEntityDescr object is better named
sipULSAddrEntityDescr.

In your LDAP scenario, then a row in the sipULSAddrTable would have
objects w/ values like so:

sipULSAddrIndex = 1    -- arbitrary
sipULSAddrType  = ipv4  -- InetAddressType textual convention from RFC 2851
sipULSAddr      = 123.45.67.89
sipULSAddrSipEntity = nonSip
sipULSAddrEntityDescr = "LDAP Server"

> URIs, as the current text can be read to imply to list all user SIP URIs

I presume the comment relates to sipUriSupportedTable in SIP-COMMON-MIB, right?
I'm not clear on exactly where you would like the description changed:
in the sipUriSupportedTable description or in the description of the
sipUriSupported object itself?

Kevin

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Kevin R. Lingle       919.392.2029
 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police.html
 Sometimes I think I understand everything, then I regain consciousness.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 Oct 2000 05:29:53 -0800

> draft-ietf-sip-mib-01.txt version of the I-D.

Indeed.

> Are you suggesting we drop both of these objects?

Yes.

> on having the ability to specify backup addresses ULS?

Probably needs discussion by those building proxies, as I can primarily
speak from our own experience. In our server, locations are derived from
several different sources

- LDAP
- an SQL database for registrations
- a set of user-configurable scripts that provide mappings from SIP user
ids to other user id's, e.g., resolution of email aliases.

While being able to change the LDAP URL via the management console is
useful, I doubt that describing or changing the others is particularly
helpful (and not likely to be feasible, given that just connecting to a
different SQL server just doesn't magically make the table definitions
appear there).

Beyond the definition, the question is whether order matters. In our
case, the order of resolution is given by the internal logic, basically
variations on "if not found there, try the next one".

> sipUriSupported object itself?

I think it was just the description.