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

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

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg