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

From: "Kostur, Andre" <[email-masked]>
Date: Fri, 20 May 2005 07:15:57 -0700

Re: Options 224+

Hold on... from the RFC:

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

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!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 20, 2005 7:05 AM
To: Bernie Volz (volz)

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 ;-) 
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Kostur, Andre" <[email-masked]>
Date: Fri, 20 May 2005 08:41:14 -0700

Isn't that the point of 124/125?  The client sends in 124 with all of the
vendor IDs it's interested in/supports, and a 3925 aware server would key
off of that (instead of 60) to choose what to fill 125 with?

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Friday, May 20, 2005 7:29 AM

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.

---

From: "Kostur, Andre" <[email-masked]>
Date: Fri, 20 May 2005 10:13:29 -0700

IMHO:
 
As a _vendor_, you MUST NOT mandate that any site-specific options be sent
back to your device.  Theoretically speaking, as a site administrator I may
wish to send option 230 back to every device that requests, because I may
have some custom DHCP tracking monitoring software that's looking for
someting in 230.  Since this is a site-specific thing (it's completely
localized to my site, and makes no sense in anybody else's site), I can use
230 without worrying about it conflicting with anything else.  Now if I
deploy a Mtel IP phone into this site (assuming Mitel has moved say the VLAN
ID option to 130), I can no longer do that since a vendor has mandated a
site-specific option to be sent back to a general-use device.
 
Besides... in most of your deployments, aren't the phones doing DHCP against
an ICP200 or MAS6000 box anyway (_both_ of which are until Mitel's control),
so upgrading whatever DHCP service on those to be 3925 compliant shouldn't
be too hard for Mitel... it's only sites like ours which are using a
different DHCP service (ours) where 3925 compliance would be dependant on
that DHCP service being compliant...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 20, 2005 10:05 AM
To: Bernie Volz (volz)
Cc: Kostur, Andre; [email-masked]
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on
"Tentatively Assigned" list re. RFC 3942

So, if we advertise vendor in option 60, and scope the response based on
this, is it: a) acceptable, b) a Bad Idea, or c) MUST NOT  to return
vendor-related info in site options range?  We had never proposed to just
blindly use a different site range without scoping it and being able to
occupy options as needed by the particular site at hand.   

Sorry to be picky about words, just trying to get it right. 

BTW, From my view at least "IP Phone" is a very slippery term indeed these
days, and moving slowly in the direction of being general purpose in many
regards.  And like many VoIP folks, we also configure other applications
which look very much like IP Phones but are not really. 

-- Peter 

	"Bernie Volz (volz)" <[email-masked]> 

20.05.05 12:45 

        To:        <[email-masked]> 
        cc:        "Kostur, Andre" <[email-masked]>, <[email-masked]>

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

Peter: 
  
Yes, you MUST NOT (per RFC 2119 terminology) use site-specific options. They
are not for vendor use. 
  
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. 
  
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. 
  
- Bernie 

  _____  

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

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

Thanks for the feedback.   

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".   

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. 

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. 

  > ... 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.   
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.   

-- Peter 

	"Bernie Volz (volz)" <[email-masked]> 

20.05.05 10:28 

       To:        "Kostur, Andre" <[email-masked]>,
<[email-masked]> 
       cc:        <[email-masked]>, <[email-masked]> 
       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). 
 
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.) 

- Bernie 

  _____  

From: Kostur, Andre [mailto:[email-masked]] 
Sent: Friday, May 20, 2005 10:16 AM
To: [email-masked]'; Bernie Volz (volz)
Cc: [email-masked]; [email-masked]
Subject: RE: [dhcwg] DHCP options 128-135 in use -- please place on
"Tentatively Assigned" list re. RFC 3942 

Re: Options 224+ 

Hold on... from the RFC: 

-----Original Message----- 
From: [email-masked] [  <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Friday, May 20, 2005 7:05 AM 
To: Bernie Volz (volz) 

Thanks Bernie, 

Will generate the I-D.