Subject: [dhcwg] Comment on a couple of option drafts that have gone by...

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Aug 2004 08:55:05 -0700

I've noticed that a couple of drafts have gone by that require the 
client to send an option to the server so that the server will know 
what to send back to the client.   In each of these cases, this seems 
like a reasonable way to solve the problem.

However, I would like to point out one problem with this, and request 
that the authors of these drafts (I'm thinking specifically of the 
haopt and tep drafts) add some text to talk about what the client 
should send in the parameter request list.

Currently the FQDN option protocol specification requires the server to 
send back an FQDN option even if the client sends a parameter request 
list and doesn't include the FQDN option code in that list.   Please 
specify in your drafts that the DHCP server must not send the reply 
option unless either no parameter request list is sent, or unless the 
option code for the option appears in the parameter request list.   
Suggested text:

The DHCP server MUST NOT send the Foo option if the client sends a 
Parameter Request List option and the code for the Foo option does not 
appear in the parameter request list, EVEN IF the Foo-request option 
appears in the client's list of options.

The reason for making this request is that we have to have special case 
code in the DHCP server to make sure the FQDN option gets sent even if 
not requested, and this adds needless complexity.   If you add text 
like what I've suggested above, you are not placing this requirement on 
the server - the server can just process the option normally when 
constructing the reply.

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

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 3 Aug 2004 21:03:39 -0400

Ted:

I can add this to the FQDN drafts (PRL for DHCPv4 and ORO for DHCPv6), but
it seems odd to do this for options that are designed to be bi-directional.
Yet, as Kim did request that I make it clear that a server can send the
option to a client even if the client doesn't supply it, it seems reasonable
that a client could request it in the PRL or ORO (without sending it). And,
if we allow that, including it in the PRL or ORO even if the option is
included by the client is OK.

I haven't checked and don't recall, but do you know whether existing clients
generally include it in the PRL today?

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> Sent: Tuesday, August 03, 2004 11:55 AM
> To: [email-masked]
> Subject: [dhcwg] Comment on a couple of option drafts that 
> have gone by...
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Aug 2004 20:57:16 -0700

> generally include it in the PRL today?

Some do, some don't.   There's special case in the ISC and Nominum DHCP 
servers to override the parameter request list in this case, and the 
code is there because of customer complaints, not because we just 
thought it might be useful.   :')

I think it's a lost cause trying to retrieve things with the FQDN 
option for DHCPv4.   I think we were careful in RFC3315 to specify the 
meaning of the ORO unambiguously, but it might still be nice to mention 
that the mere presence of the FQDN option in the message to the server 
does not override the ORO, and that if the client doesn't list the FQDN 
option in the ORO, it will not get one back from the server.

BTW, it's actually useful in the case of the FQDN option to _not_ 
include it in the ORO - most DHCP clients probably don't _care_ whether 
the server did the update.   They want to tell the server what they'd 
like done, but if the server doesn't do the update, nothing about the 
client's behavior is likely to change.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Aug 2004 21:19:17 -0700

Hm, let me be more clear about one thing.   I agree that it makes 
intuitive sense that if you have a two-way option, you needn't mention 
it in the ORO.   However, this makes implementation potentially more 
complicated, particularly in DHCPv6.   So I think there's some real 
value in just requiring that any option the client wants to get back 
should be specified in the ORO, rather than having some options where 
you have to ask for them in the ORO, and some options where you do not.