Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt

On Fri, Aug 27, 2004 at 01:08:32PM +0700, Robert Elz wrote:
>     Date:        Fri, 20 Aug 2004 08:44:14 -0400
>     From:        "Bernie Volz" <volz@cisco.com>
>     Message-ID:  <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com>
> 
>   | I'm OK to restricting the Lifetime Option to replies to
>   | Information-Request's.
>   | 
>   | The client MUST ignore a Lifetime Option that is in any message other than a
>   | REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime
>   | Option number in an ORO except when sending an INFORMATION-REQUEST message.
>   | 
>   | The server MUST NOT include the Lifetime Option in any message other than a
>   | REPLY to an INFORMATION-REQUEST.
> 
> I've been reading all of the messages on this topic (catching up) and I
> haven't managed to find a reason why anyone would want to add this kind
> of restriction, I just don't see the need.
> 
> You seem to all be imagining that things have to get much more complex
> for the clients if they get two timer values, and they're different.
> But that's nonsense.

I pretty much agree with what you say. The reason the option isn't
needed when you have leases, is of course that you can set the lease
time short, just to ensure that client update other config. I agree that
it could still be useful though.

I don't know what people think, I have no strong feelings myself, but
we could relax things a bit perhaps. But there is some added complexity
and it isn't essential. It could also be extended later if necessary.

We could tweak the spec to allow what you say, if there's agreement on
that. But most of all, I want to come to some conclusion really soon.

I posted a mail with subject "Attempt at text for
draft-ietf-dhc-lifetime-02" where I tried to write text that most so
far seems to agree with. Most of it is based on inputs from discussions
on mailing list.

Bernie gave some comments that I plan to include.

I did not say any about what should happen if some config data is
removed from one client update to the next. Do you really want that
in? I'm not sure I do, since as also some others agreed to, it's a
more generic problem. If I were to write text, I would say that it
should indeed be removed.

Stig

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