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

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Jan 2005 10:37:40 -0500

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.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of response does not
constitute support, and the document will not be submitted to the IESG
without explicit feedback from the dhc WG,

"Information Refresh Time Option for DHCPv6" describes a DHCPv6 option
for specifying an upper bound for how long a client should wait before
refreshing information retrieved from DHCPv6.  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 DHCPv6 server
to refresh its configuration..  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-lifetime-03.txt

- Ralph Droms 

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 25 Jan 2005 15:29:02 +0900

>>>>> On Mon, 24 Jan 2005 10:37:40 -0500, 
>>>>> Ralph Droms <[email-masked]> said:

> without explicit feedback from the dhc WG,

I confirmed that my minor comments to the previous version have been
addressed, and I support this version to be submitted to the IESG.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Syam Madanapalli <[email-masked]>
Date: Tue, 25 Jan 2005 12:30:57 +0530

In section 3. Information refresh time option definition

   ....

   Note that it is only an upper bound.  If the client has any reason to
   make a DHCPv6 request before the refresh time expires, it should
   attempt to refresh all the data.
....

Is it necessary to refresh all the data when the refresh time has not yet
expired
or it can refresh only the the required data?

Isn't it sufficient to refresh whatever the data that is required to
refresh?
And refresh all the data when the refresh time expired.

-Syam

---

From: Robert Elz <[email-masked]>
Date: Tue, 25 Jan 2005 15:08:20 +0700

Date:        Tue, 25 Jan 2005 12:30:57 +0530
    From:        Syam Madanapalli <[email-masked]>
    Message-ID:  <[email-masked]>

  | Is it necessary to refresh all the data when the refresh time has not yet
  | expired or it can refresh only the the required data?
  | 
  | Isn't it sufficient to refresh whatever the data that is required to
  | refresh?

How can anything possibly benefit from that?   If you're sending a query,
and getting the answer, you may as well get everything, rather than having
to do the other half again later.

If, as in the normal case, none of the data has actually changed, that's
generally the end of it, there's nothing else to do, apart from arranging
to refresh it all again later some time.

If however, something has changed, the node, and the net it is connected
to, is almost certainly better off using the new data ASAP, rather than
stubbornly hanging onto the old data just because you were told in the
past that you are permitted to do so.

kre

---

From: Joe Quanaim <[email-masked]>
Date: Fri, 28 Jan 2005 11:17:08 -0500

I support this document being submitted.

Joe Quanaim.