Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAdA-0007kF-Im; Fri, 20 May 2005 12:45:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZAd8-0007kA-K1 for dhcwg@megatron.ietf.org; Fri, 20 May 2005 12:45:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05477 for ; Fri, 20 May 2005 12:45:43 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZAuW-0007BB-NH for dhcwg@ietf.org; Fri, 20 May 2005 13:03:45 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 20 May 2005 12:45:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4KGjYdw025927; Fri, 20 May 2005 12:45:34 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 12:45:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Date: Fri, 20 May 2005 12:45:25 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB212B3CFF@xmb-rtp-20a.amer.cisco.com> Thread-Topic: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Thread-Index: AcVdWmtZcTS7ypHFQguI/Mr0JLiZgQAAHeag From: "Bernie Volz \(volz\)" To: X-OriginalArrivalTime: 20 May 2005 16:45:26.0917 (UTC) FILETIME=[5332C350:01C55D5B] X-Spam-Score: 0.8 (/) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab Cc: dhcwg@ietf.org, "Kostur, Andre" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0809687626==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0809687626== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55D5B.53180C1D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C55D5B.53180C1D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Peter: =20 Yes, you MUST NOT (per RFC 2119 terminology) use site-specific options. They are not for vendor use. =20 I'm not saying that option 60 is the trigger for 125, just that it could be. As could any number of other things - such as the mac address or client id, option 124 data, ... you name it. =20 I assume your IP phones are just that ... they aren't general purpose clients? If that is the case, using Option 60 is certainly possible and should not cause any issues since you're doing what that option is intended for - identifying the vendor of the client making the request. =20 - Bernie ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Friday, May 20, 2005 12:41 PM To: Bernie Volz (volz) Cc: Kostur, Andre; dhcwg@ietf.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 =09 =09 [I assume IANA does not need the noise, so removed from thread.] =09 Thanks for the feedback. =20 =09 Just to be clear, what we had discussed was to only pass back options in the site range based on having received option 60 containing the vendor info. Interpretation is, for a given site, here are the options for this application. Agree this is not preferred, just another thing we had looked at. It appear you folks would be stronger than "not preferred". =20 =09 Any feedback on using option options 60 / 43? It is a bit flawed for multiple vendors in the same exchange, I know. But is it well supported in the field today is the real question.=20 =09 Issue with using options 124/125 exchanges remains it is not out there very widely now, and deployment always takes time ... so we have a gap. Administrative pain to construct the data, likely for several different flavors of server, is just that ... a pain. But a pain we'd rather avoid or at least minimize. Forcing upgrades to the DHCP environment in the field is also a pain, and a cost that many will not be happy to suck up if there are other means.=20 =09 > ... One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. =20 Hmmm, perhaps I need to re-read. My understanding was option 124 is used to pass a vendor unique ID (or several), along with any specific data (opaque to the DHCP process), and the server returns info in 125 against the same vendor ID. Why would option 60 be used as a trigger at all. =20 =09 -- Peter=20 =09 =09 =09 =09 =09 "Bernie Volz (volz)" =20 20.05.05 10:28=20 =20 To: "Kostur, Andre" , =20 cc: , =20 Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 Yup, using the site specific option range is really a bad idea (whatever that range is).=20 =20 You can expect servers to start supporting RFC 3925 ... and the more people that want to start using this, the more likely the server vendors will start supporting it. Even if a server doesn't explicitly support it, most of them allow you to enter an arbitrary option number and data to return -- while having to construct the option data by hand is very tricky, at least it provides a means for supporting the option on older servers. (Perhaps it requires a tool where you configure the vendor specific data and it spits out some ASCII binary form that is usable to be cut and pasted into most server's configurations.)=20 =20 One thing that isn't as clear as it could be in RFC 3925 is how a client communication interested in a certain vendor option set. Part of the reason for this is that it really is up to each vendor to determine that. But that does make it more difficult for server vendors to provide appropriate triggers. Likely most servers will require you to classify the incoming request in some way and then the options configured for that class are returned. A common trigger for this might be option 60.=20 =20 - Bernie=20 =09 =09 ________________________________ From: Kostur, Andre [mailto:akostur@incognito.com]=20 Sent: Friday, May 20, 2005 10:16 AM To: 'peter_blatherwick@mitel.com'; Bernie Volz (volz) Cc: dhcwg@ietf.org; iana@iana.org Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively Assigned" list re. RFC 3942 =09 Re: Options 224+=20 Hold on... from the RFC:=20 Some vendors have made use of site-specific option codes that violate=20 the intent of the site-specific options, as the options are used to=20 configure features of their products and thus are specific to many=20 sites. This usage could potentially cause problems if a site that=20 has been using the same site-specific option codes for other purposes=20 deploys products from one of the vendors, or if two vendors pick the=20 same site-specific options.=20 If you start using options 224+, you're just going to end up in the same boat that we're in now. Those options are for site-specific options. If your phones are going to be using those options (and, BTW, we have some of these phones....) then it's no longer a site-specific option!=20 -----Original Message-----=20 From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com ]=20 Sent: Friday, May 20, 2005 7:05 AM=20 To: Bernie Volz (volz)=20 Thanks Bernie,=20 Will generate the I-D. =20 No, nothing to do with PXE. We were aware of that one, and believe there are other conflicting usages as well.=20 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. =20 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 ;-)=20 =09 ------_=_NextPart_001_01C55D5B.53180C1D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Peter:
 
Yes, you MUST NOT (per RFC 2119 terminology) = use=20 site-specific options. They are not for vendor use.
 
I'm not saying that option 60 is the trigger = for 125, just=20 that it could be. As could any number of other things - such as the mac = address=20 or client id, option 124 data, ... you name it.
 
I assume your IP phones are just that ... they = aren't=20 general purpose clients? If that is the case, using Option 60 is = certainly=20 possible and should not cause any issues since you're doing what that = option is=20 intended for - identifying the vendor of the client making the=20 request.
 
- Bernie

From: peter_blatherwick@mitel.com=20 [mailto:peter_blatherwick@mitel.com]
Sent: Friday, May 20, = 2005=20 12:41 PM
To: Bernie Volz (volz)
Cc: Kostur, Andre; = dhcwg@ietf.org
Subject: RE: [dhcwg] DHCP options 128-135 in = use --=20 please place on "Tentatively Assigned" list re. RFC = 3942


[I assume IANA does = not need the=20 noise, so removed from thread.]

Thanks for the feedback.  

Just to be clear, what we had discussed was to only pass back = options=20 in the site range based on having received option 60 containing the = vendor=20 info.  Interpretation is, for a given site, here are the options = for this=20 application.  Agree this is not preferred, just another thing we = had=20 looked at.  It appear you folks would be stronger than "not = preferred".=20  

Any feedback on = using=20 option options 60 / 43?  It is a bit flawed for multiple vendors = in the=20 same exchange, I know.  But is it well supported in the field = today is=20 the real question.

Issue with=20 using options 124/125 exchanges remains it is not out there very = widely now,=20 and deployment always takes time ... so we have a gap. =  Administrative=20 pain to construct the data, likely for several different flavors of = server, is=20 just that ... a pain.  But a pain we'd rather avoid or at least = minimize.=20  Forcing upgrades to the DHCP environment in the field is also a = pain,=20 and a cost that many will not be happy to suck up if there are other=20 means.

  =  > ...=20 One thing that isn't = as clear as it=20 could be in RFC 3925 is how a client communication interested in a = certain=20 vendor option set.  
Hmmm, perhaps I need to re-read.  My = understanding=20 was option 124 is used to pass a vendor unique ID (or several), along = with any=20 specific data (opaque to the DHCP process), and the server returns = info in 125=20 against the same vendor ID.  Why would option 60 be used as a = trigger at=20 all.  

-- = Peter=20




"Bernie Volz (volz)"=20 <volz@cisco.com>=20

20.05.05 10:28 =

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



Yup, using the site specific option range is really a bad = idea=20 (whatever that range is).
 
You can expect=20 servers to start supporting RFC 3925 ... and the more people that want = to=20 start using this, the more likely the server vendors will start = supporting it.=20 Even if a server doesn't explicitly support it, most of them allow you = to=20 enter an arbitrary option number and data to return -- while having to = construct the option data by hand is very tricky, at least it provides = a means=20 for supporting the option on older servers. (Perhaps it requires a = tool where=20 you configure the vendor specific data and it spits out some ASCII = binary form=20 that is usable to be cut and pasted into most server's = configurations.)=20
 
One thing that isn't as clear as it could be in = RFC 3925 is=20 how a client communication interested in a certain vendor option set. = Part of=20 the reason for this is that it really is up to each vendor to = determine that.=20 But that does make it more difficult for server vendors to provide = appropriate=20 triggers. Likely most servers will require you to classify the = incoming=20 request in some way and then the options configured for that class are = returned. A common trigger for this might be option 60. =
 
- Bernie

From: Kostur, Andre=20 [mailto:akostur@incognito.com]
Sent: Friday, May 20, 2005 = 10:16=20 AM
To: 'peter_blatherwick@mitel.com'; Bernie Volz=20 (volz)
Cc: dhcwg@ietf.org; iana@iana.org
Subject: = RE:=20 [dhcwg] DHCP options 128-135 in use -- please place on "Tentatively = Assigned"=20 list re. RFC 3942

Re: Options = 224+

Hold on... from the = RFC:

   Some vendors = have made use=20 of site-specific option codes that violate
  = the intent of=20 the site-specific options, as the options are used to
  configure features of their products and thus are = specific=20 to many
  sites.  This usage = could=20 potentially cause problems if a site that
  = has been using=20 the same site-specific option codes for other purposes
  deploys products from one of the vendors, or if = two vendors=20 pick the
  same site-specific=20 options.

If you start using options = 224+, you're=20 just going to end up in the same boat that we're in now.  Those = options=20 are for site-specific options.  If your phones are going to be = using=20 those options (and, BTW, we have some of these phones....) then it's = no longer=20 a site-specific option!=20

-----Original = Message-----
From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20
Sent: Friday, May = 20, 2005 7:05=20 AM
To: Bernie Volz = (volz)

Thanks Bernie,

Will generate the I-D. =  

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

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

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

------_=_NextPart_001_01C55D5B.53180C1D-- --===============0809687626== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0809687626==--