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

From: PARK SOO HONG <[email-masked]>
Date: Tue, 03 Aug 2004 20:17:38 +0000 (GMT)

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

So I simply wrote some text in my draft.

The DHCP client will use this option to create a tunnel end-point
address

for configuring IPv6-over-IPv4 tunnel. The client may
receive tunnel services

in this option that it does not support or
has not been configured to access.

Likewise, a client may receive
an option that tunnel services for which no

corresponding DHCP
option was supplied. Clients will interpret this option

in a
system-specific manner whose specification is outside the scope of

this document.

Isn't it enough to satisfy your concern ?

This text is our implementation-basis

Regards

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Aug 2004 15:25:59 -0700

> Isn't it enough to satisfy your concern ?

No, my concern is not related to what you're talking about.   My 
concern is actually unrelated to the work you are doing - I'm just 
asking you to add some text to try to get client implements to be 
consistent in what they do with the parameter request list.   It's not 
your fault that this is (IMHO) necessary - the problem is that the 
parameter request list option is poorly specified, and I'd like 
implementors of this option to implement to the more stringent 
interpretation of the specification, rather than the more lax 
implementation.

In order to get client implementors to do this, I am asking you to add 
some text which will (I hope) cause client implementors to assume that 
the DHCP server will behave in a certain way.   If they believe that a 
DHCP server will very likely not send a tep option if the client 
doesn't request it in the parameter request list, then they will 
request it in the parameter request list.   If they do not believe 
this, then they may send a parameter request list but omit the tep 
option code from the list, thinking it is not necessary to include it.

I don't actually care if server implementors follow the requirements 
I'm asking you to add - I just care that client implementors have 
reason to think that servers might follow these requirements.

---

From: Kim Kinnear <[email-masked]>
Date: Tue, 03 Aug 2004 19:55:52 -0400

At 06:25 PM 8/3/2004, Ted Lemon wrote:
>No, my concern is not related to what you're talking about.   My concern is actually unrelated to the work you are doing - I'm just asking you to add some text to try to get client implements to be consistent in what they do with the parameter request list.   It's not your fault that this is (IMHO) necessary - the problem is that the parameter request list option is poorly specified, and I'd like implementors of this option to implement to the more stringent interpretation of the specification, rather than the more lax implementation.
>
>In order to get client implementors to do this, I am asking you to add some text which will (I hope) cause client implementors to assume that the DHCP server will behave in a certain way.   If they believe that a DHCP server will very likely not send a tep option if the client doesn't request it in the parameter request list, then they will request it in the parameter request list.   If they do not believe this, then they may send a parameter request list but omit the tep option code from the list, thinking it is not necessary to include it.
>
>I don't actually care if server implementors follow the requirements I'm asking you to add - I just care that client implementors have reason to think that servers might follow these requirements.

        Ted,

        Thank you for such a clear statement of this issue.  I
        agree that the parameter request option is poorly
        specified, and I remember my astonishment the first time
        I heard the interpretation that a DHCP server should send
        *every* option with which it is configured (and not just
        the options that were requested in the parameter request
        list).  That wasn't my interpretation of the DHCP
        draft/RFC and it seems it wasn't yours either.

        I also agree with your goal -- that client implementors
        *must* ask (via the paramter request list) for options
        that they need, and not assume that the DHCP server will
        just send send them by magic.

        I believe that the way to achieve that goal is to simply
        put that in the RFC -- that a client that needs this
        option MUST request it via the parameter request list. 

        I strongly believe that saying that a DHCP server MUST
        NOT send this option unless a client requests it is very
        much not the way to achieve this end.  This will require
        special case code in every DHCP server which wants to be
        compliant with this draft (and future RFC).  I see this
        as a "cure worse than the disease".

        Let us just say what we mean -- a client that wants this
        option MUST request it by using the parameter request
        list.  Period.

        Cheers -- Kim

---

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

>         as a "cure worse than the disease".

How about making it a SHOULD NOT?   I don't really want to add a 
special case to my server to do this either, but I do want there to be 
strong language there about it.   I agree that it's really a client 
requirement, and that we should say what we really want, but I have 
found that client implementors quite frequently only skim the spec, so 
it'd be nice if there were two places where they could read something 
that would make them want to do the right thing, and not just one such 
place.