The intend of the proposed procedure is to use DHC Protocol at the bootstrap time in order to receive the IP address(es) of SIP (Proxy) Server(s). In other words, a kind of RAS Discovery procedure for SIP.

The purpose to this e-mail is not to compare between the two procedures. My thinking is that end devices should 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 this proposal (see the attachment) is by no means SIP-specific. There are many application level protocols that require this sort of functionality, i.e. they relay on application-specific Server (or a list of possible Servers), whose IP address(es) should be discovered. The examples only in our area are H.323 and MEGACO. Taking a look into "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. More then that: in order to solve this allocation problem "groups of related options may be combined into a single specification and reviewed as a set by the IESG".