Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-timezone-option-02.txt

From: [email-masked]
Date: Tue, 18 Jul 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: A Timezone Option for DHCP
	Author(s)	: E. Lear, P. Eggert
	Filename	: draft-ietf-dhc-timezone-option-02.txt
	Pages		: 10
	Date		: 2006-7-18
	
DHCP defines an option for a server to deliver to a client offset
from UTC.  This information in and of itself is not sufficient for
devices to portray local time both accurately and consistently.  This
memo specifies new options for both DHCPv4 and DHCPv6 to do so.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-timezone-option-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-timezone-option-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-timezone-option-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: John Schnizlein <[email-masked]>
Date: Tue, 18 Jul 2006 16:49:35 -0400

On Jul 18, 2006, at 3:50 PM, [email-masked] wrote:
> ...
> ...

This draft is much improved by the specification of separate options,  
among which clients can choose the most useful one, elimination of the  
operating-system-specific option, and better clarity on the proposed  
options.

Unfortunately, it still contains the following unnecessary text, which  
conflicts with existing practice and section 4 of  
draft-ietf-dhc-dhcpv6-rfc868-servers-00.txt, which was the subject of a  
WG last call from June 6 to June 20.  It does no harm to continue the  
existing practice, although operational use of the existing offset  
option could be improved by providing options for when to change the  
offset and to what to change it.  What is the benefit of deprecating  
what is in use?

John

> 7.1.  Deprecation of Time Offset Option
>
>    Because this option provides a superset of functionality to the
>    previous IPv4 time offset option (tag 2), and in order to maintain
>    consistency between IPv4 and IPv6 implementation, the older option  
> is
>    deprecated.  Implementations of the time offset IPv4 option SHOULD
>    implement this option as well.  Others SHOULD instead implement this
>    option.

---

From: Shane Kerr <[email-masked]>
Date: Tue, 18 Jul 2006 23:03:41 +0200

>> http://www.ietf.org/internet-drafts/draft-ietf-dhc-timezone-option-02.txt

<snip/>

> offset and to what to change it.  What is the benefit of deprecating

The text is not unnecessary.

The timezone options contain all of the information in the time offset
option, and more. The time offset does not provide enough information to
properly configure clients, although with a certain amount of trickery
it can come close.

Implementors should be encouraged to move to the timezone options.

- --
Shane

---

From: Eliot Lear <[email-masked]>
Date: Wed, 19 Jul 2006 09:39:59 +0200

John,

Thanks for your contributions to this discussion.
> draft-ietf-dhc-dhcpv6-rfc868-servers-00.txt, which was the subject of
> a WG last call from June 6 to June 20.  It does no harm to continue
> the existing practice, although operational use of the existing offset
My sense is that you are correct that there is not yet consensus for the
existing text.  Perhaps now is a good time to try and come to consensus,
and I would ask the chairs for their assistance.

I have two concerns:

    * First, the existing mechanism is broken and cannot handle DST
      transitions nor can it easily integrate with such general purpose
      platforms as Microsoft Windows, UNIX, and some Java stacks.  This
      is the reason Paul and I wrote the draft in the first place. 
    * Second, once one arrives at the first conclusion as a matter of
      best practice - and I do believe there is consensus on that point,
      if one has developed a better alternative, that is the alternative
      that should be recommended, and not a menu of approaches.  A menu
      has the nasty habit of only working sometimes in the best of
      circumstances, and having bad interactions in the worst.  I am of
      course well aware that there will be a long slow transition in
      some cases from the existing option.

And so I believe deprecation of the time offset option is appropriate. 
Shane has graciously offered some alternative wording to make the text a
bit less confusing.  I am happy to see further improvements if you
believe we could better convey the above points.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Jul 2006 09:23:57 -0500

> believe we could better convey the above points.

Yup, I'm not actually sure there isn't rough consensus.   John's been a
big advocate for not deprecating the option, but I'm not sure why.
It's not like CableLabs has to stop using it tomorrow if it gets
deprecated - deprecated simply means "if you're choosing between the two
options in a new implementation, choose the one that's not deprecated."
  Why is that controversial?

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 19 Jul 2006 11:13:42 -0700

> offset and to what to change it.  What is the benefit of deprecating  

It's my opinion, and understanding from what I've been told from
the community of our customers, that the time-offset-option is only
in very limited use by those people who had no other option before
them: they used what they had, and it hurt them.  The 'use cases'
for this option can only be described as 'war stories'.

If I were to suggest that we should deprecate "the use of hammers
for the purpose of driving screws", you would not question the
wisdom of that statement.

So, I believe, it is here.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg