RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942

Thanks Bernie, 

Will generate the I-D. 

No, nothing to do with PXE.  We were aware of that one, and believe there 
are other conflicting usages as well.

We have looked at RFC 3925 (options 124 / 125) of course, and I certainly 
like it -- very clean.  However we do have a strong concern that it may 
take some time before it becomes well deployed, since it is still quite 
new (October 04).   Instead (or possibly supplementally) we are looking at 
using options 60 / 43 to exchange vendor info, or option 60 alone to 
identify the vendor with retuned info in other options in the site range 
(224 and above) scoped based on the vendor in the request. 

Is there a BCP or anything to give good advice on "best" approaches? Since 
there are no doubt about a zillion other vendors in the same position, it 
would be good if we all did at least roughly the same thing ;-)

-- Peter

"Bernie Volz (volz)" <volz@cisco.com>
19.05.05 22:59

        To:     <peter_blatherwick@mitel.com>, <dhcwg@ietf.org>, <iana@iana.org>
        cc: 
        Subject:        RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively 
Assigned" list re. RFC 3942

Thanks Peter.

I assume your usage of these option numbers has nothing to do with PXE.

Regarding the I-D, yes it would be useful to have that. But as there are 
conflicting uses of these option numbers, moving away from their use is 
highly recommended. So, it is up to you.

The I-D would be to document the existing usage.

If you make use of the RFC 3925 vendor options going forward, that would 
mean you would not need to standardize the new options via the IETF.

Yes, there will be a list. I am waiting until early June to compile that 
as I wanted to give people until the end of May to respond. I expect to 
send it to IANA and hopefully they'll publish that on the DHCPv4 options 
page.

This list will primarily indicate the options that are in use, but I don't 
expect to give details of the data format, etc. That is what future I-Ds 
will hopefully do. 

- Bernie

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of peter_blatherwick@mitel.com
Sent: Thursday, May 19, 2005 2:10 PM
To: dhcwg@ietf.org; iana@iana.org
Subject: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively 
Assigned" list re. RFC 3942

[ sorry, resend to add a subject for tracking...  please ignore previous ] 

Hello DHC WG and IANA, 

Regarding RFC 3942, this is to document our (Mitel Networks) use of DHCP 
options 128-135 in the current vendor-specific range, and to request these 
be placed on the "Tentatively Assigned"  list. 

Our usage is as follows.  All are related to configuration of IP Phones 
(and similar devices) in a VoIP network. 

Option    Usage 
======    ===== 
128       TFPT Server IP address (for IP Phone - specific sw load) 
129       Call Server IP address 
130       Discrimination string (to identify vendor) 
131       Remote statistics server IP address 
132       802.1P VLAN ID 
133       802.1Q L2 Priority 
134       Diffserv Code Point 
135       HTTP Proxy for phone-specific applications 

Please confirm that these will go on the Tentatively Assigned list (or 
perhaps some already are). 

Also, it is not completely clear whether an I-D documenting this same 
information is or is not required.  We are currently looking at getting 
away from this scheme, in favor of better defined / standardized 
vendor-specific methods.  Given this, and the high likelihood of clashes 
over the same options wanted for use by others, we do not currently intend 
to pursue standardization of these options.  Is an I-D required to 
complete the process of putting the options on the Tentatively Assigned 
list?   

While we're on it, is there already, or will there be, a definitive list 
of all the options in Tentatively Assigned state?   

Regards, 
Peter Blatherwick 
Sr. Solutions Architect, 
Mitel Networks 