RE: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02

["Bernie Volz" <[e-mail]>]

Hi Stig:

Comments below, in line prefixed by "BV>".

You don't document the format of the option? But, this is just a portion of
the text?

- Bernie

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Stig Venaas
> Sent: Wednesday, August 25, 2004 11:16 AM
> To: [e-mail]
> Subject: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02
> 
> 
> I've tried to update the text based on all the suggestions 
> and comments received. I may still try to improve the 
> language, but please read the text below and let me know if 
> you have problems with what it says. Lines from the draft are 
> prefixed by "|". I have some comments/questions inline. I'm 
> hoping that we can come to agreement on the text in 1-2 
> weeks, so that I can finalize version 02, which then 
> hopefully can go to WGLC.
> 
> 
> |              Information Refresh Time Option for DHCPv6
> 
> What do you think of this name? I think the problem with just 
> "refresh time option" is that it sounds more like an option 
> for refreshing time...
> 
> |Abstract
> |
> |  This document describes an option for specifying an upper 
> bound for  
> | how long a client should wait before refreshing information 
> retrieved  
> | from DHCP.  It's useful for stateless DHCPv6 where there are no  

BV> "It is used with stateless DHCPv6 as there are no"

> | addresses or other entities with lifetimes that can tell 
> the client  
> | when to contact the DHCP server to refresh its configuration.
> 
> |1. Introduction
> |
> |  DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6  
> | hosts.  However, many hosts will use stateless 
> autoconfiguration as  
> | specified in [RFC 2462] for address assignment, and use 
> DHCPv6 only  
> | for other configuration data.  This other configuration data will  

BV> Add reference to [RFC 3736]?

> | typically have no associated lifetime, hence there may be no  
> | information telling a host when to refresh its DHCP configuration  
> | data.
> |
> |  This option may be useful in unstable environments where 
> unexpected  
> | changes are likely to occur, or for planned changes, including  
> | renumbering where an administrator can gradually decrease 
> the value  
> | as the event nears.
> |
> |  It may also be useful to allow the client to detect within an  
> | appropriate amount of time when a specific service change has been  
> | made, e.g. the addition of a new NTP server, or a change of 
> address  
> | of a DNS server within the local network.  See [RENUMREQS] for  
> | further details.
> 
> |3. Information refresh time option definition
> |
> |  The information refresh time option specifies an upper 
> bound for how  
> | long a client should wait before refreshing information retrieved  
> | from DHCP.  It's only used for replies to Information-request  

BV> "It is only used in Reply messages in response to Information-Request"

> | messages.  In other messages there will usually be other 
> options that  
> | indicate when the client should contact the server, e.g. addresses  
> | with lifetimes.
> |
> |  Note that it's only an upper bound.  If the client has any 
> reason to  
> | make a DHCP request before the refresh time expires, it should  
> | attempt to refresh all the data.
> |
> |  There are a number of potential reasons for the client to 
> contact the  
> | server before the refresh time expires.  One reason might be other  
> | options that have some associated lifetime that is shorter 
> than the  
> | refresh time.  Other reasons might be a new IPv6 prefix 
> announced by  
> | a router, or that a server becomes unreachable on the 
> address learnt  
> | from DHCP.  The client may also determine that it needs to request  
> | additional options.
> 
> Do you think it's ok that client might update information if 
> a server becomes unreachable? Say you learn DNS or NTP server 
> address from DHCP, and at some point the resolver or NTP 
> client determines that it can't reach the server. Would it 
> then be ok to make the dhcp client request new data? An issue 
> might be that if a server goes down, thousands of clients may 
> try to update their DHCP config almost simultaneously... I'm 
> only trying to give an example though, but is it a good one?

NO. Like Rich, I think this would be an extremely bad idea. Let's remove it.

I'd replace the two above paragraphs with:

  The Information Refresh Time option's time is an upper bound as to when
  the client SHOULD refresh its configuration information. A client MAY
  refresh this information before this time, such as if one or more
  prefixes for addresses in the configuration information expire.

> 
> |  Note that this also means that it doesn't make sense to have  
> | different refresh time options for different data, since when the  
> | client has reason to refresh some of its data, it should 
> also  refresh 
> | the remaining data.

I'd reword this to simply state that there is ONE time for all configuration
data.

> |
> |  The expiry of the refresh time in itself does not in 
> anyway mean that  
> | the client should remove the data.  The client should keep it's  
> | current data while attempting to refresh it.  The client is 
> however  
> | free to fall back to other mechanisms if it cannot refresh 
> the data  
> | within a reasonable amount of time.
> |
> |  In some cases the client uses a default refresh time IRT_DEFAULT.  
> | The recommended value for IRT_DEFAULT is 86400 (24 hours).  The  
> | client implementation should allow for this value to be configured.
> 
> What do you think of 24 hours? I've got suggestions for 1, 
> 6-12, at least 12 hours and more from you.

I like 24 hours.

> 
> |3.1. Client behaviour
> |
> |  A client MUST include this option in the Option Request 
> Option (ORO)  
> | when sending Information-request messages to the DHCP server.  A  
> | client MUST NOT include this option in the ORO in any other 
> messages.

Perhaps: "If a client supports this option, it MUST ..."

> |
> |  If the reply to an Information-request message does not 
> contain this  
> | option, the client MUST behave as if the option with value  
> | IRT_DEFAULT was provided.
> |
> |  A client MUST also use the default refresh time IRT_DEFAULT if it  
> | receives the option with value less than 600.
> 
> Do you agree with a minimum like this? It should make it 
> harder to do bad things, and I don't see a use for <10 
> minutes. If <600, would you rather use 600 than IRT_DEFAULT?

As I suggested it, I like it. Perhaps we should specify IRT_MINIMUM as a
parameter?

> 
> |  If a client contacts the server to obtain new data or 
> refresh some  
> | existing data before the refresh time expires, then it SHOULD also  
> | refresh all data covered by this option.
> |
> |  When the client detects that the refresh time has expired, 
> it SHOULD  
> | try to update its configuration data by making a new DHCP 
> request as  
> | follows.
> |
> |  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].  
> | Note that this delay is in addition to the rules specified in [RFC  
> | 3315].
> |
> |  Then it can make the DHCP request to update the 
> configuration.  The  
> | message MUST be created and transmitted according to [RFC 
> 3315].  For  
> | an Information-request message it must be done according to 
> the rules  
> | for creation and transmission of Information-request messages in  
> | section 18.1.5 of [RFC 3315].
> 
> We could perhaps say clearly that it must send Information-request.
> 
> I think there's one thing we should discuss that is related 
> to this. What if client at some point determines that it 
> wants to request an address (switch to stateful mode). Then 
> we should perhaps say that client should also refresh this 
> data and forget the previous refresh time. What if it makes a 
> request but does not get a reply with new data? Perhaps it 
> should only forget refresh time when it gets new data, so 
> that it can keep using it if not?

Let's not mention this. Clients should always request this other conf. info.

> 
> |3.2. Server behaviour
> |
> |  A server sending a reply to an Information-request message SHOULD  
> | include this option if it's included in the ORO of the request.  It

BV> "if it is".

> 
> Do you agree with SHOULD, or do you want MUST? My thinking is 
> that server should allow the refresh time to be configured, 
> and probably have IRT_DEFAULT as the default value (although 
> some servers may prefer some other default, e.g. if made for 
> us in a specific environment). Rather than sending the value 
> IRT_DEFAULT it might just as well not include it.

BV> If configured in the server, the server MUST return it (if requested). I
do not think the server should treat this option specially - such as supply
a default if not configured.

> 
> Do you think we should talk about this being configurable on 
> the server and server default, or is it all pretty obvious 
> and better left to the implementation?
> 

BV> Pretty obvious.

> |  MUST NOT be included if it's not in the ORO of the request.
> 
> Is this ok? There's no harm in including it, but it's totally 
> pointless since we require client to include it in ORO, so if 
> not in the request, the client will ignore it.

BV> No, drop it. A server is always free to include any other options it
wants. If a client doesn't support it, it will ignore it.

> 
> |  When server sends a message that is not a reply to an 
> Information-  
> | request message, it MUST NOT include the option.
> 
> It would be sufficient to say that it's only to be included 
> if requested by client, since client MUST ONLY request it in 
> Information-request messages. So this paragraph could be omitted.

BV> I'd drop it. If a client were to include this option in an ORO for a
non-Information-Request message, and it was configured in the server, the
server might return it (again, want to avoid special code in the server) and
I think that is OK. The client is wrong but so what - what the client might
do with this time is unknown but since it is broken, do we really care? Fix
the client.

> 
> |  The option value MUST be no less than 600.

BV> I'd leave this to the client.

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


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