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

[Stig Venaas <[e-mail]>]

On Tue, Aug 03, 2004 at 09:33:29AM -0400, Joe Quanaim wrote:
> 
> JINMEI Tatuya / ???????????? wrote:
> [...]
> > 2. the usage of the lifetime option for other exchanges than
> >    Info-req/Reply exchanges.
> >
> >    I'm even not 100% sure if the lifetime can be used for the other
> >    types of exchanges.  Probably it can according to the draft, but
> >    then I'll have several questions on how to use it.
> >
> >    For example, the draft says:
> >
> >      Before making the request it MUST wait for a random amount of time
> >      between 0 and INF_MAX_DELAY.  INF_MAX_DELAY is defined in [RFC 3315].
> >
> >   Is this also applies to the other cases even if INF_MAX_DELAY is a
> >   dedicated parameter for Info-req?  If so, is it really valid?
> 
> Isn't this duplicating rfc 3315?  Removing it would prevent any subsequent 
> updates to rfc 3315 from conflicing with this statement.

So what you're saying is that should say 1 sec, rather than
INF_MAX_DELAY? Or are you saying that shouldn't specify random delay
at all?

At first I didn't see the need for random delay since there is one
prior to the first information request according to rfc 3315, but as
someone said it might be required. If for instance the client checks
for expired lifetime every second or less often.

> >   Also, how does the client exactly react to the expiration event for
> >   the other cases?  For example, consider the following scenario:
> >
> >   - the client performs Solicit->Advertise->Request->Reply exchanges,
> >     and gets an IPv6 address allocated, a DNS server address X, and an
> >     associated lifetime T.
> >   - before the timeout "T1" for the allocated address passes, lifetime
> >     T expires.  In this case, should the client restart the entire
> >     session from Solicit?  Or should the client send a renew message?
> >     If so, the renew message also tries to update the allocated
> >     address even if it's too early?  Or should the client even start
> >     Information-request/Reply exchanges just to update the DNS address
> >     information?
> 
> Using this option in a stateful transaction makes things more complicated.  
> The lifetime option can expire between t1, t2, or the valid lifetime of an 
> address.  As Jinmei Tatuya notes, what should the client be expected to do?  
> Restart the message exchange; just do an information-request; etc.
> 
> Any negotiated value for t1, t2, or valid lifetime of an address could take 
> precedence over the lifetime option.  This essentially makes the option 
> stateless only, but it simplifies the resulting changes to a client 
> implementation.

I'm happy with this. If anyone got other opinions, please speak up.
I'll mail text suggestion soon,

> Joe Quanaim.

Thanks,

Stig

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