Subject: DHCP option tags for SIP(?)

From: "Orit Levin" <[email-masked]>
Date: Fri, 3 Mar 2000 13:32:51 -0500

Hello!
Sorry for bringing this issue once again.

It is not about the necessity of the proposed procedure. I think it is useful and should be pursued. My attitude is that end devices may support more then one procedure for the same purpose (especially when it is a configuration issue).  In this way they are flexible and can be deployed in various environments.

My concern is that the functionality described in the current proposal is by no means SIP-specific. There are many APPLICATION LEVEL protocols that require this functionality, i.e. they relay on application-specific Server (or a list of possible Servers), whose IP address(es) should be discovered at bootstrap. Academically thinking it is strange to allocate "a whole DHCP option" to one specific application. 

Practically thinking, the best example in VoIP area is MEGACO which is "heavily dependant" on its Server(s). From VoIP terminal, flexibly implementing both SIP and MEGACO, I would expect it to use the same bootstrap procedure for both applications.

Looking into the "Procedure for Defining New DHCP Options" RFC-2489 you will find that "the option number space for publicly defined DHCP options has almost been exhausted" and this is the whole reason for the new procedure defined by RFC-2489.

Based on this, I would like to suggest SIP Working group to revise their proposal by defining the use of this option in flexible  "application level" point of view.

Best Regards,
Orit Levin
RADVision Inc.
Director of Product Management
575 Corporate Drive Suite 420
Mahwah, NJ 07430
Tel: 1 201 529 4300  (230)
Fax: 1 201 529 3516
www.radvision.com
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 03 Mar 2000 13:48:44 -0500

> Orit Levin wrote:
> It is not about the necessity of the proposed procedure. I think it is
> useful and should be pursued. My attitude is that end devices may
> support more then one procedure for the same purpose (especially when
> it is a configuration issue).  In this way they are flexible and can
> be deployed in various environments.
> 
> My concern is that the functionality described in the current proposal
> is by no means SIP-specific. There are many APPLICATION LEVEL
> protocols that require this functionality, i.e. they relay on
> application-specific Server (or a list of possible Servers), whose IP
> address(es) should be discovered at bootstrap. Academically thinking
> it is strange to allocate "a whole DHCP option" to one specific
> application.

Actually, if you look at the current DHCP options, that's exactly how it
works: SMTP and WWW, to name just two examples, have their own options,
as do time servers, font servers, etc. - all applications.

> 
> Practically thinking, the best example in VoIP area is MEGACO which is
> "heavily dependant" on its Server(s). From VoIP terminal, flexibly
> implementing both SIP and MEGACO, I would expect it to use the same
> bootstrap procedure for both applications.
> 
> Looking into the "Procedure for Defining New DHCP Options" RFC-2489
> you will find that "the option number space for publicly defined DHCP
> options has almost been exhausted" and this is the whole reason for
> the new procedure defined by RFC-2489.
> 
> Based on this, I would like to suggest SIP Working group to revise
> their proposal by defining the use of this option in flexible
> "application level" point of view.

Since I'm not sure what exactly you propose, but...

The problem is two-fold:

a) Many systems don't need all of H.323, Megaco, SIP, whatever. Given
the limited space in DHCP payloads, overloading a single option with
multiple sub-options means that the client can't choose which ones it
needs. (E.g., a SIP phone would not care the least about Megaco
servers.)

b) Implementation: All existing DHCP servers are limited to either
strings or a list of IP addresses. Adding suboptions means that existing
servers can't be used. Waiting until DHCP servers incorporate this
special option could take years, not even counting the installed-base
issue of WinNT4 servers, etc. 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs