Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Feb 2003 15:37:19 -0500 (EST)

This message announces a WG last call on "Time Configuration Options for
DHCPv6" <draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt>. The last call will
conclude on Friday, 2/28.

draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt specifies describes the
DHCPv6 options for time related configuration information: NTP Servers
and IEEE 1003.1 POSIX Timezone specifier.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt

- Ralph Droms

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

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 Feb 2003 18:35:11 +0700

There are a few issues in this doc that should be attended to.
I suspect that most of them are really issues with the posix
timezone format, but it should still be possible to clear things
up in this doc so it is complete on its own (where possible, keeping
it compatible with posix is, I suppose, a good idea).

The NTP part is fine - though the security considerations should probably
also note that time accuracy can be crucial to some security algorithms
(being able to manipulate time can allow expired certificates to gain a
new life, etc...) and so systems with any particular security requirements
should take special care.   That is, the "time critical applications" might
be security applications, which makes this of special concern.

Should it actually say SNTP instead of NTP, since that's the RFC that is
referenced?

It would be nice if the timezone option could also carry an ado type
timezone specifier (as used by almost all systems that actually care
about dealing with time zone representation).   That's the name of one of
the defined timezone specifications for the world, which conveys MUCH
more information than a posix timezone string can possibly convey.

I suspect that all that's needed to make this work is to make the
(first) Offset optional.   That is, if there's no offset, then the
name is treated as an index into the timezone database (if it exists)
- on most systems, this means as a file name (relative to some system
dependent directory) and all the other data are obtained from there.

Systems which can't use this form should just be sent a standard posix
string, of course.

The description of the offset after Dst doesn't indicate whether that
offset is an offset from UTC or from local standard time.

The text ...

	If no Offset follows Dst, then
        Dst is assumed to be one hour ahead of standard time

suggests that it is an offset from standard time (or can certainly
be read that way), but the example that includes

	EST5EDT4

suggests that it is an offset from UTC (which I believe is correct).
This should be made clear.

The format "Mm.n.d" is allowed to allow (simplistic) rules for daylight
saving to be encoded (simplistic as there's no way to say "second last Sunday"
and various other possibilities - but that's a posix limitation I expect).

But ...

	Mm.n.d   The ``d''th day, (0 <= d <= 6) of week

doesn't give a clue as to which digits correspond to which days.   That
is, is the first (0th) dat of the week Sunday, Monday, or some other day?
This should be clarified.

For the example (eastern US, a pretty boring timezone to have chosen - except
for the issues of just what it includes, which isn't relevant here, the meaning
of the string should explained in more detail.

That is, the 116th day is some particular date - say which one (then people
can see how the calculation happened).   Same for the 298th day.   The "at 2am"
should be explicit (here as well as elsewhere where it is stated) that this
means "local clock time" (ie: DST starts at 02:00 standard time, and ends
at 02:00 daylight saving time).

kre

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Wed, 19 Feb 2003 20:58:07 +0530

Robert,

Thanks for your thorough review.
See my reply inline...

~Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Robert Elz
> Sent: Wednesday, February 19, 2003 5:05 PM
> To: [email-masked]
> Subject: Re: [dhcwg] WG last call on
> draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt 
> 
> 

Agreed. I will add note on "time critical security applications".

> Should it actually say SNTP instead of NTP, since that's the 

As NTP is the generic term referencing both NTP and SNTP, i have made
it as NTP.

> Systems which can't use this form should just be sent a standard posix

Please note that this information is sent by the server to the clients.
DHCPv6 server will serve a network with varieties of systems. If it sends
Time zone as you specified above, then the systems which can't use it 
in this form may be in trouble. That's why the time zone 
representation in kept sync with IEEE specification.

> offset is an offset from UTC or from local standard time.

The Offset is always relative to UTC. 

Offset   Indicates the value one must add to local time to
               arrive at UTC, of the form:  [+|-]hh[:mm[:ss]].  

> be read that way), 

Yes. You are correct. Its offset from standard time, as it clearly says.

> but the example that includes
> 
> 	EST5EDT4
> 

The example is also correct, since "offset" is specified, its relative
to UTC. 

> This should be clarified.

Agreed. I add a note on this.
Day 0 is Sunday.

> 
> 
> For the example (eastern US, a pretty boring time zone to have 
> chosen - except

Agreed. I will add that.

EST5EDT4,116/02:00:00,298/02:00:00

This says that:
The standard time zone is in 5 hours lag to UTC.
The DST is 4 hours lag to UTC.
Day light savings starts at April 26 02:00 AM
and ends at October 25 02:00 AM

Thanks once again for your comments