Subject: [dhcwg] draft-raj-dhc-tftp-addr-option-02

From: "H. Peter Anvin" <[email-masked]>
Date: Fri, 08 Jun 2007 11:33:35 -0700

Hello,

I looked over the RFC 3942 status report and the above option.  I'm a
bit surprised by the following statement:

>    Small devices, such as IP phones, have a need for downloading their
>    configuration from a TFTP server on the network.  There are commonly
>    accepted methods to discover this server via DHCP; the "sname" field
>    in the DHCP header [2] , the "TFTP Server name" option (#66) [3] .
>    Both of these sources of information, however, contain the TFTP
>    server's hostname.  That hostname must then be translated to an IP
>    address.  The usual method to accomplish this would be DNS. [4] This
>    means the firmware in a small "network appliance" device would need
>    to implement the DNS protocol in order to perform this translation.
>    This unacceptably increases the firmware code size.

In my experience, this is most commonly discovered via the "siaddr"
field in the DHCP response.  I think it would be advisable if this
document described the intended semantic differences between this option
and the siaddr field, as I'm a bit concerned that different bootloaders
might have different expectations of what this file should contain.

If this is specifically intended for a configuration file, it probably
should be named "configuration file server".  In that sense, it would be
a companion option to option 209 specified in draft-ietf-dhc-pxelinux-01.

	-hpa

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Richard Johnson <[email-masked]>
Date: Thu, 14 Jun 2007 13:33:02 -0700

Sorry it took me a while to get in touch with the people who actually  
make use of this option and let them address this.  Here are the  
reasons given for going with a new option for this:

1) siaddr field is/was not configurable on some DHCP servers.
	e.g  Microsoft's DHCP server
2) siaddr field only allows for one IP address.
3) some DHCP servers seem to fill in their own IP address as siaddr!
	e.g. Novell's DHCP server
4) some customers were already using siaddr for something else

We have further discussed this option, however, and it has become  
apparent that it really shouldn't be a general purpose "TFTP server  
address" option.  It's only used for VoIP devices to find their  
configuration server and this functionality can (and probably will)  
migrate away from using TFTP.

We're thinking the option should instead be titled, "VoIP Device  
Configuration Server address(es)".  In this respect it's sorta like  
other options which already exist such as:

    68      Home-Agent-Addrs         N    Home Agent  
Addresses                  [RFC2132]
    69      SMTP-Server              N    Simple Mail Server  
Addresses          [RFC2132]
    70      POP3-Server              N    Post Office Server  
Addresses          [RFC2132]
    71      NNTP-Server              N    Network News Server  
Addresses         [RFC2132]
    72      WWW-Server               N    WWW Server  
Addresses                  [RFC2132]
    73      Finger-Server            N    Finger Server  
Addresses               [RFC2132]
    74      IRC-Server               N    Chat Server  
Addresses                 [RFC2132]
    75      StreetTalk-Server        N    StreetTalk Server  
Addresses           [RFC2132]
    76      STDA-Server              N    ST Directory Assist.  
Addresses        [RFC2132]

and many others.

/raj

---

From: "H. Peter Anvin" <[email-masked]>
Date: Thu, 14 Jun 2007 13:43:40 -0700

> other options which already exist such as:

I would drop the "VoIP Device" prefix, unless you think there is a
strong reason to limit this to only VoIP devices.  I can definitely see
it as desirable to be able to request that a configuration file is
obtained from a different location than the boot file.

	-hpa

---

From: Richard Johnson <[email-masked]>
Date: Thu, 14 Jun 2007 14:53:35 -0700

If we have a more generalized "Configuration Server Address(es)",  
wouldn't that present potential problems in cases where some devices  
on a link are of one type and need one "configuration server", while  
other devices on the same link are of a different type and thus need  
a different "configuration server"?  Maybe distinction could be made  
using the Class-ID, but I'm not sure that helps all that much for  
most situations/customers.  I would think it would be better to have  
a more specific "VoIP configuration server" such that configuration  
on the DHCP server for that option would end up only applying to  
clients which ask for that particular option, while other devices  
could ask for other "configuration server" options.  Isn't this the  
primary reason for currently having so many different types of "XYZ  
server address" options?

/raj

---

From: "H. Peter Anvin" <[email-masked]>
Date: Thu, 14 Jun 2007 15:36:04 -0700

Richard Johnson wrote:
> wouldn't that present potential problems in cases where some devices on
> a link are of one type and need one "configuration server", while other
> devices on the same link are of a different type and thus need a
> different "configuration server"?  Maybe distinction could be made using
> the Class-ID, but I'm not sure that helps all that much for most
> situations/customers.  I would think it would be better to have a more
> specific "VoIP configuration server" such that configuration on the DHCP
> server for that option would end up only applying to clients which ask
> for that particular option, while other devices could ask for other
> "configuration server" options.  Isn't this the primary reason for
> currently having so many different types of "XYZ server address" options?

Using that logic, we'd run out of option codes pretty darn quickly.

I think that's exactly why the Vendor Class Identifier exists.

In particular, consider your statement:

> I would think it would be better to have a more specific "VoIP configuration server" such that configuration on the DHCP server for that option would end up only applying to clients which ask for that particular option, while other devices could ask for other "configuration server" options.

Here you seem to imply that there is something magic about VoIP devices
that makes them distinct from "other" devices.  That *exactly* same
argument can be made for, quite literally, any number of other device
classes.  Furthermore, it's entirely likely that, say, Cisco VoIP phones
will need an entirely different configuration file than, say, Avaya or
Nortel, making this argument even more specious.

	-hpa

---

From: Richard Johnson <[email-masked]>
Date: Thu, 14 Jun 2007 15:43:26 -0700

Yep, I realized all of that when I said it. :)

Of course, there already exist many different "configuration server"  
options, of which I only named a few in a previous message.  I guess  
they're all historical and the WG would currently be supporting the  
idea that no new "XZY server address" options would be allowed  
because all such new options should be Vendor Specific suboptions.

I would tend to agree with this, actually.  I wonder if this is the  
more general view of the WG?

/raj

On Jun 14, 2007, at 3:36 PM, H. Peter Anvin wrote:

>> I would think it would be better to have a more specific "VoIP  
>> configuration server" such that configuration on the DHCP server  
>> for that option would end up only applying to clients which ask  
>> for that particular option, while other devices could ask for  
>> other "configuration server" options.
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Jun 2007 15:54:18 -0700

> more general view of the WG?

I'd rather stuff got documented, in general.   But if something  
really is vendor-specific, it ought to go into vendor-specific  
options; I think that an i-d describing it is still desirable, though.

---

From: "H. Peter Anvin" <[email-masked]>
Date: Thu, 14 Jun 2007 16:16:53 -0700

Ted Lemon wrote:
> I'd rather stuff got documented, in general.   But if something really
> is vendor-specific, it ought to go into vendor-specific options; I think
> that an i-d describing it is still desirable, though.
> 

I think that having "configuration file server" and "configuration file
path" options still make sense, though.  They're vendor-independent at
the syntactic level, meaning that you can at least provide places to put
them into the DHCP configuration file without having to write a
syntactical specification for the server to know what you're talking about.

	-hpa

---

From: Bud Millwood <[email-masked]>
Date: Fri, 15 Jun 2007 10:01:02 +0200

> syntactical specification for the server to know what you're talking about.

I agree.

I had a short discussion with Bernie about this a few months ago (concerning 
DHCPv6). I was under the impression that general-purpose "config server/ 
config path" options would be a good idea for many types of devices. His 
input, at the time, was simply to explain why these options weren't needed 
for DOCSIS 3.0 (they're vendor-specific).

- Bud

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 16 Jun 2007 14:34:39 -0400

The fundamental question is whether this is documenting existing usage
so that this meets the requirements put forward in RFC 3942 to document
that usage in order to have the option assigned, or whether we are
trying to develop a new standard.

If we're documenting existing usage (which is I believe the point of the
draft), then calling it something specific to what it is used for is
appropriate.

If we're trying to develop a new standard, let the debate continue.

- Bernie

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 18 Jun 2007 10:42:13 +0900

> draft), then calling it something specific to what it is used for is

Agreed. I think that documenting existing solutions is a good idea.

> If we're trying to develop a new standard, let the debate continue.

One thing about the new standard that wasn't brought up yet (I think) is
that even with multiple devices requiring different types of configuration
(Cisco, Avaya phone example), there are many ways of providing them with
correct type-specific configuration with just one 'config option' and still
get meaningful results, for example

- have policies per device (or DUID-mask if they're allocated in some way
  that determines device type), or

- have policies per MAC-mask (ugly)

Pushing it just to all clients wouldn't make sense though (well, at least
if the client type of every client was not known). 'Hey, all clients, here
is a configuration blob you can try.. if you can parse it.. and won't have
problems with it.. use it.' doesn't sound like ideal option semantics to me
;)

Therefore I think that there would be _some_ value for defining just one
configuration blob option, as I think that offering all N types of
configuration payload for a device which cares about 0-1 types would not be
useful.

Cheers,

-Markus