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

[Joe Quanaim <[e-mail]>]

Stig Venaas wrote:
> 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.

Ok.  I felt like the entire statement was repeating rfc 3315 and could be 
removed.  Looking again, I think you are trying to differentiate between the 
first info request (which 3315 dictates) and enforce the INF_MAX_DELAY for 
subsequent info requests after a lifetime expires.  I am okay with that.  I 
would have considered this to be a new exchange and therefore under the 3315 
guidelines, but having it spelled out does not hurt.

Also, if a client is checking for an expired lifetime every second, that's a 
problem.  Perhaps we should add a statement saying that a client should not 
recheck lifetimes without waiting a period of at least half the received 
lifetime.  It would need to be should instead of must to allow client reboots 
and such, but it would at least make bombarding a server with requests 
inappropriate behavior.

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

I feel like this statement is sufficient for the current ia's: na, ta, and pd.

> > Joe Quanaim.
>
> Thanks,
>
> Stig

Thanks,
Joe Quanaim.


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