Subject: [dhcwg] Second dhc wg last call on "Time Protocol Servers and Time Offset Options for IPv6 DHCP"

From: Stig Venaas <[email-masked]>
Date: Tue, 06 Jun 2006 13:32:41 +0200

This messages announces a new wg last call on "Time Protocol Servers and 
Time Offset Options for IPv6 
DHCP"<draft-ietf-dhc-dhcpv6-rfc868-servers-00.txt>. The last call will 
conclude at 1700 ET on 2006-06-20.

There were no responses to the previous last call. It's critical that 
those who support the draft respond; no response is not sufficient for 
the draft to pass. So please respond by the above deadline with your 
support or any issues you might have.

Stig

Stig Venaas wrote:
> This message announces a wg last call on "Time Protocol Servers and Time 
> Offset Options for IPv6 DHCP" 
> <draft-ietf-dhc-dhcpv6-rfc868-servers-00.txt>. The last call will 
> conclude at 1700 ET on 2006-05-22.
> 
> 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 discussion does not
> represent positive support.  If there is no expression of support for
> acceptance during the WG last call, the document will not be advanced
> to the IESG.
> 
>  From the abstract:
> The Time Protocol Servers option for IPv6 DHCP (RFC 3315) carries the
> IPv6 addresses of servers that a host should use for the Time
> Protocol (RFC 868).  The Time Offset option carries the offset in
> seconds from Coordinated Universal Time (UTC) that a client may use
> to determine its local time.
> 
> This draft is available as
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-rfc868-servers-00.txt 
> 
> 
> Stig
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg

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

---

From: Ralph Droms <[email-masked]>
Date: Tue, 06 Jun 2006 07:53:10 -0400

Eliot - CableLabs DOCSIS 3.0 specification will use both the RFC 868 servers
option and the time offset option.  While
draft-ietf-dhc-timezone-option-00.txt is likely a better solution than the
time offset option (for that matter, NTP would likely be an improvement over
NTP), DOCSIS 3.0 will specify RFC 868 time service and the DHCPv6 equivalent
of the time offset option for consistency with previous DOCSIS specs.

Therefore, I think we should continue with the definition of the time offest
option.

- Ralph

On 6/6/06 7:38 AM, "Eliot Lear" <[email-masked]> wrote:

> Stig Venaas wrote:
>> This messages announces a new wg last call on "Time Protocol Servers
>> and Time Offset Options for IPv6
> This group has accepted a working group document that contains a better
> alternative to the time offset option.  I would support the advancing of
> the above draft with only the 868 servers, and otherwise ask that we
> defer this last call until we have a more clear result as to the other
> timezone draft (draft-ietf-dhc-timezone-option-00.txt).  Of course, it
> seems only fair in return that I do my best to make that draft the best
> it can be, so I will put out a new version shortly that removes
> suboptions and uses multiple options.
> 
> Thanks,
> 
> Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 06 Jun 2006 13:38:27 +0200

Thanks,

Eliot

---

From: John Schnizlein <[email-masked]>
Date: Tue, 6 Jun 2006 13:23:25 -0400

I support advancing this draft to Proposed Standard RFC (through the  
IESG).
I apologize for neglecting the earlier last call; my questions about  
the RFC868 version were answered long ago.

John

On Jun 6, 2006, at 7:32 AM, Stig Venaas wrote:

>> This message announces a wg last call on "Time Protocol Servers and  
>> Time Offset Options for IPv6 DHCP"  
>> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-rfc868- 
>> servers-00.txt Stig

---

From: Eliot Lear <[email-masked]>
Date: Wed, 07 Jun 2006 08:30:16 +0200

Ralph,

To be clear...
> of the time offset option for consistency with previous DOCSIS specs.

draft-ietf-dhc-timezone-option-00.txt (and its soon to be released
successor -01) both call for deprecation of time offset because it is
broken.  To my knoweldge not a single general purpose computer
implements it.  Is there anything we can do to get Cable Labs to
reference the new work?  We should shortly be ready for WGLC.

Eliot

---

From: John Schnizlein <[email-masked]>
Date: Wed, 7 Jun 2006 02:49:59 -0400

The brokenness of the time offset - lack of time to change offset 
information - can be fixed by adding options for NextOffset and 
nextChange, with advice that clients use the algorithm in 
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg06029.html and 
get new options before the change after nextChange.

This approach was advocated, with compromise based on discussion at the 
last meeting and on the list, in 
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg06114.html after 
being proposed in 
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05987.html.

John

---

From: Eliot Lear <[email-masked]>
Date: Wed, 07 Jun 2006 09:43:17 +0200

John,
> This approach was advocated, with compromise based on discussion at
> the last meeting and on the list, in
> http://www1.ietf.org/mail-archive/web/dhcwg/current/msg06114.html
> after being proposed in

Yes, you mentioned this proposal.  We disagree (strongly).  To implement
offset in most general purposes OSes, even with your proposal, would
require substantial amounts of work on both the server AND the client. 
Far better to give the rules, since they are conveniently available.

Eliot

---

From: John Schnizlein <[email-masked]>
Date: Wed, 7 Jun 2006 07:00:41 -0400

The reason Dynamic Host Configuration calls these things options is 
that hosts can choose which to request.  Assuming you are correct that 
"general purpose OSes" would prefer to obtain and use an index into a 
historic database of timezone information, an option for that should be 
made available.

However, insisting on deprecating an option that some special-purpose 
operating systems use, rather than fixing a problem with changing the 
offset twice a year, ignores the reality that the other option has 
utility for different hosts on the Internet.  Why not let hosts that 
use the existing Time Offset option (2) continue to use it, and fix the 
problem with it that you identified?

Making these separate options enables hosts to use the the Parameter 
Request List option (55) to indicate their preference to the DHCP 
server.

John

---

From: Eliot Lear <[email-masked]>
Date: Wed, 07 Jun 2006 15:19:31 +0200

John Schnizlein wrote:
> historic database of timezone information, an option for that should
> be made available.
For purpose of clarity, when I wrote "general purpose OSes" I meant
Windows, MacOS, Linux, Solaris, AIX, and some embedded Java stacks (I
can't speak to all of them).  I have not reviewed VXworks and I am aware
that some small devices don't include ANY support for timezones (at all)
and cannot understand the difference between wall clock and UTC.
> use the existing Time Offset option (2) continue to use it, and fix
> the problem with it that you identified?

There are two reasons to deprecate something.  One is when it is not
used, and the other is when it should not be used.  For example, SNMPv1
is plenty used but deprecated in favor of SNMPv3.  Here I suggest
something similar.  The time offset option is broken, and when used as
directed requires substantial operational overhead to even attempt to
maintain correct time through a DST transition for those OSes that code
to it.  And so it seems to me that the appropriate approach is to
provide an approach that works more generally, requires less special
code, has a lower operational overhead, and most importantly produces
correct local time.
> Request List option (55) to indicate their preference to the DHCP server.
The forthcoming draft -01 (it's in the internet-drafts queue) breaks the
previous suboptions out into separate options, based on this group's
wishes.  I presume it could then be used with option 55?

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Wed, 07 Jun 2006 11:05:24 -0700

> Request List option (55) to indicate their preference to the DHCP server.
Not to single out John, but I think this discussion is creating heat and 
not light.   The time offset option is reasonably fine for cable 
modems.   Requiring them to implement the fancier option Eliot is 
working on is not necessary.   It would be a shame if regular O.S. 
vendors implemented the time offset option and not Eliot's option, but I 
haven't seen any sign that this has happened in DHCPv4-land, and so I 
see no reason to presume that it will happen in DHCPv6-land.   The 
time-offset option simply isn't adequate for any operating system with 
stable storage.

So, with respect, I would like to suggest that it is fine to pass this 
draft as is.   I think John agrees with this.   Eliot doesn't, and I 
respect his reasons for objecting, but I don't think they need 
necessarily hold back the advancement of this draft.

My vote is to pass the draft through the last call as written.