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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 7 Jun 2006 16:08:45 -0400

I, for one, don't see why we'd want to deprecate it. For example, if
DOCSIS is going to use this, it will be around for a long time. So, why
deprecate it. Sure, it isn't perfect and isn't complete information, but
for a lot of applications it is "good enough". For those that don't find
that the case, they are more than free to use the new options.

And, let the market decide. If 10 years from now no one uses this option
and you or someone else has the energy to want to deprecate it, go for
it.

- Bernie

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Wednesday, June 07, 2006 4:03 PM
> To: Ted Lemon
> Cc: Stig Venaas; [email-masked]; Ralph Droms (rdroms); Bernie 
> Volz (volz); John Schnizlein (jschnizl)
> Subject: Re: [dhcwg] Second dhc wg last call on "Time 
> Protocol Servers andTime Offset Options for IPv6 DHCP"
> 
> Ted Lemon wrote:
> > Stig Venaas wrote:
> >> How about adding some text to Ralph's draft summarizing the issues
> >> with offset and saying that one should rather implement what is
> >> specified in Eliot's?
> > I think we're dropping into the IETF slow zone here.   
> There's really
> > no need to put any admonitory language in here.   We can put it in
> > Eliots draft if necessary, since he's revising it, but the fact is
> > that nobody who's doing an operating system is going to use the time
> > offset as more than a UI hint, because it's incomplete.   
> It's useful
> > for deciding where to put the cursor in the system time zone
> > configuration UI, but it's not useful for actually setting the
> > timezone on _any_ modern operating system, and so there is zero risk
> > that it will be used this way.   Let's not rev the document 
> for this.
> 
> Right.  If the group is going to go forward with the Time Protocol
> Servers draft as is, you needn't update it.  But I believe 
> we'll need to
> have a healthy discussion on list about whether or not to 
> deprecate the
> offset function, and whether to do it now or later.  I will 
> not, by the
> way, be at Montreal.
> 
> Eliot
> 

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 08 Jun 2006 08:45:40 +0200

Hi Bernie,

> and you or someone else has the energy to want to deprecate it, go for
Why then was SNMPv1 deprecated?  The market CLEARLY prefers it to v3.

Obviously we don't have authority to tell people who don't work for us
how to code.  All we have is collective experience and in some cases
wisdom to recommend what the right thing to do is.  Of course, it helps
a lot if one has the benefit of good information.  In this case the
cable companies that I've talked to have NOT raised a concern about the
modems themselves but about any necessary changes needed by back end
systems to support new options.  And if you think about it for a while
this shouldn't come as much of a surprise given that the little frisbees
consumers use as firewalls are often LINUX based.

And so I'm concerned that CableLabs and the IETF are both chasing each
other's tail on this issue, and that we should just recommend the right
thing.  In this case I believe the right thing is to recommend something
BETTER than the offset option.

Eliot

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 8 Jun 2006 09:06:17 -0700

> and you or someone else has the energy to want to deprecate it, go for

Depending on the day of the week, I might agree.

Except that the information in the time-offset option is a subset of
what is provided in one of the options in Elliot's draft.

So they don't actually do "different things", just "different formats."

This is 'throwing spaghetti at the wall to see what sticks', and it's
no longer an appropriate behaviour for IETF to continue to participate
in.

I'm not in favor of advancing this draft with the time-offset present
in it, unless someone can demonstrate a use case where the information
desired can not be gleaned from the POSIX string, and can only be had
from the time-offset option's format as presented.

-- 
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

---

From: Ralph Droms <[email-masked]>
Date: Thu, 08 Jun 2006 12:10:44 -0400

David - I think the issue with this draft is more along the lines of "what
spaghetti is currently stuck to the wall".  The CableLabs DOCSIS 3.0
specification team would very much like to have the same time offset option
in DHCPv6 as has been used in DHCPv4, for consistency.  Perhaps foolish
consistency, but consistency nonetheless...

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 8 Jun 2006 11:18:32 -0700

> spaghetti is currently stuck to the wall".  The CableLabs DOCSIS 3.0

I'm willing to agree that the draft is attempting to photographically
duplicate spaghetti stuck to one wall to a different wall on the basis
that one of the guests likes how it's shaped.

And that's probably as far as we should stretch this metaphor.

> consistency, but consistency nonetheless...

I can accept the statement that the widget outside of their DHCP client
which processes the integer value, digests it into the system's time
keeping systems, represents running code.

But this isn't DHCP running code, is it?  It's a layer behind that?

---

From: Ralph Droms <[email-masked]>
Date: Thu, 15 Jun 2006 11:26:17 -0400

dhc WG members - I don't see any benefit or disadvantage to deprecating the
existing DHCPv4, so I think any effort expended on deprecating the DHCPv4
option is wasted.  Perhaps our cycles would be better used elsewhere.

Because there is no running code for the DHCPv6 time offset option, there is
nothing lost by moving to some new option for DOCSIS 3.0 DHCPv6.  However,
the cable service providers (the customers for DOCSIS 3.0) have politely
expressed their desire for a DHCPv6 option that is consistent with the
DHCPv4 option.  Although I think this discussion is also a waste of time, I
will go back to the DOCSIS 3.0 IPv6 focus team and ask if it would be
acceptable to change the spec to use some version of the new timezone
option.   I will also advise the DOCSIS FT that the least painful solution
might be to define a CableLabs specific option for the timezone, rather than
invest any additional energy in this discussion.

- Ralph