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

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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
> On Behalf Of Ted Lemon
> Sent: Tuesday, August 03, 2004 11:55 AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Comment on a couple of option drafts that 
> have gone by...
> 
> 
> 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
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg