Subject: [dhcwg] Re: UPDATED dhc WG last call on draft-ietf-dhc-lifetime

From: Mark Thompson <[email-masked]>
Date: Wed, 2 Feb 2005 19:49:14 +0000

> There were no responses to the first WG last call on "Information 
> Refresh
> Time Option for DHCPv6" <draft-ietf-dhc-lifetime-02.txt>.  The authors 
> have
> submitted a new revision, draft-ietf-dhc-lifetime-03.txt, for which 
> there
> will be a new WG last call.  This new last call will end at 1700EST on
> Mon, 2005-02-07.

I know it's bad form to apologise ahead of speaking, but I've not 
followed previous discussion on this draft and so these issues/comments 
may have been covered before. I've spoken with Stig about this briefly 
and he's of the opinion that, as this is at WGLC,  the draft should 
stand up on its own, and as such I shouldn't feel too bad about posting 
;-)

Of course, these are all my personal opinion and I'll gladly discuss 
motivation behind my recommendations.  I've provided suggested text 
where appropriate.

Editorial suggestions:

* Line 63: Tighten language? Suggestion:

%<
    retrieved from a DHCPv6 server.  It is used with stateless DHCPv6 as
    there are no addresses or other entities with lifetimes that can tell
    the client when to contact a DHCPv6 server to refresh its
    configuration.
%<

* Line 99: Clumsy read. Suggestion:

%<
    configuration data.  Therefore, an option for the server to inform 
the
    client when it should refresh data is needed.

    This option is useful in situations including:
%<

* Line 115+: Awkward categorisation. I see what the intention is, but 
the three items in the list are inconsistently presented. My suggestion 
is to move the administrator actions to later in the draft (or just 
delete?) and replace the list with something like this:

%<
        - Unstable environments where unexpected changes are likely to
          occur, such as when a service or server fails.

        - Unstable environments undergoing a controlled transition, e.g.
          during network renumbering or topology restructuring.

        - Stable environments where new services are to be phased-in as
          old are phased-out.
%<

* Line 142: Use normative language?

%<
If the client has any reason to make a DHCPv6 request before the 
refresh time expires, it SHOULD attempt to refresh all of the data 
configured by previous INFORMATION-REQUEST interactions.
%<

I think that even with this editorial change, this clause would benefit 
from a sentence of justification - even if it is as simple as Robert 
Elz's suggestion on Jan 25.

* Line 148: Sentence is redundant given previous paragraph. If removed, 
the second sentence in the existing paragraph will need adapting, e.g. 
"Reasons that a client may refresh early include the need for 
additional..."

* Line 155: "It doesn't make sense..." strikes me as too colloquial. A 
suggestion:

%<
    data. Having different refresh time values for different data would 
be
    inappropriate in light of the recommendation that a client refresh 
all
    configuration data when it has reason to refresh any. Because of
%<

* Line 157: normative: s/must/MUST/

* Line 171: Clumsy, suggest:

%<
    current data while attempting to refresh it.  The client is free to
    fall back to mechanisms other than DHCPv6 if it cannot refresh its
    data within a reasonable amount of time.
%<

* Line 175: Repeated use of "configuration information", suggest:

%<
    When a client receives a Reply to an Information-Request that
    contains configuration information, it should install it only after
    removing any configuration resulting from responses received
    previously. It should also remove information that is missing
    from the new information set, e.g. an option might be left out or
    contain only a subset of what it did previously.
%<

HOWEVER - see 'substantive comment' below.

* Line 193: A sentence explaining the motivation behind 24hrs as a 
value for IRT_DEFAULT might be useful here. Personally, I'm unclear as 
to why a day is appropriate when a site's DNS RR TTL describing the 
service's location may be very different.

* Line 239: Is there such a thing as a "possibly infinite" amount of 
time? Suggest:

%<
    messages.  Without a maximum value, a client may have invalid
    configuration information and have impeded functionality until a
    new DHCPv6 request issued and an opportunity to refresh
    availed.  There may ...
%<

Substantive comment:

The idea that the absence of configuration data in a Reply to an 
Information-Request should cause a client to "de-configure" itself 
causes me a bit of a headache.

Granted, it makes a DHCPv6 server implementation easier to just have a 
'standard' answer to I-Rs that contain all the stateless configuration 
data that the server has to hand and not have to explicitly step 
through option codes in the I-R so as to work out precisely what set of 
information the client wants; likewise it makes client implementations 
easier ("just gimme foo" and then parse everything that's returned).

However, just because configuration data is no longer advertised where 
it previously was should not, in my opinion, trigger a client to 
de-configure those services. There may not be sufficient state kept in 
the client for it to know where that configuration data came from.

An example (perhaps contrived?): A client's NTP servers might be 
configured by other means locally, perhaps then overridden by 
information received as a product of stateless DHCPv6. What should that 
client do if a future Reply no longer contained NTP service 
configuration data (nor any indication that there previously was data 
there)? Should it "wind back" to the previous (external) configuration 
data (which requires historical state, with some notion of provenance)? 
Should it de-configure the service to 'null'? or should it do nothing 
and keep the (possibly broken) configuration gleaned from an earlier 
Reply to an I-R?

Granted there is no mechanism for keeping state in the DHCPv6 server of 
which clients may have seen what configuration data - the whole point 
is to be stateless. However, I think it's asking a bit much to instruct 
clients to maintain information about the state of the world before any 
DHCPv6-gleaned configuration data was received, about how new 
configuration data was learnt, and about which individual options that 
it might choose to care about are unwound when no longer seen.

We can't "time out" option configuration data because we explicitly 
demand that lifetimes apply across all options uniformly as part of the 
spec, and it would require separate timers per configuration option 
item to expire (e.g.) NTP data if not seen in subsequent Replies whilst 
renewing lifetime of, for instance, domain name.

A simple solution (perhaps) would be to include a "No Data" value for 
configuration data, but I'm guessing that this isn't the draft in which 
to suggest such a thing?

Once the substantive comment has been clarified, I'd be happy with the 
draft progressing. In fact, I think lifetimes are an important concept 
that are necessary for stateless DHCPv6 to be deployed.

Mark/

--
Electronics and Computer Science, a School of the University of 
Southampton
http://www.ecs.soton.ac.uk/

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Feb 2005 13:51:23 -0700

On Feb 2, 2005, at 12:49 PM, Mark Thompson wrote:
> configuration data, but I'm guessing that this isn't the draft in 
> which to suggest such a thing?

This is actually worse than the status quo, because now you have a 
mechanism for erasing manually-configured data on the client.   The 
right way to implement this is precisely as you suggest - to keep track 
of what information you got last time, so that you can remove it if you 
don't see it in a subsequent message.

Additionally, you assume that the DHCP server has some means of knowing 
that data that was sent previously is no longer valid, but this is not 
the case - it's quite possible that you've changed networks, and the 
reason the data isn't valid is because you're talking to a different 
DHCP server.

Generally squeaking, I think this is a non-problem.   It's possible 
that the draft needs to be more explicit about the clients' 
responsibilities, and if you think that's so I'd be interested in 
seeing proposed alternative text, but I think your model for how the 
client and server ought to interact is slightly broken.   :'}

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 3 Feb 2005 13:38:57 -0500

Mark:

What if you unplug the client from network A and then plug it into network B
without a reboot.

Now, the DHCP client receives new information. And, may not (as in your
example) receive any NTP information, and let's say the OLD information it
had contained non-global addresses (perhaps link-local or the new global
local or whatever those darn things are called). And, there's also no way
for the DHCP server (which is a different server) to even know what the
client got before!!!

I can't see how using the old information would be of any benefit. The
client MUST deconfigure this information.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> Sent: Wednesday, February 02, 2005 3:51 PM
> To: Mark Thompson
> Cc: [email-masked]
> Subject: Re: [dhcwg] Re: UPDATED dhc WG last call on 
> draft-ietf-dhc-lifetime
> 
>