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

["Vijayabhaskar A K" <[e-mail]>]

Robert,

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

~Vijay

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Robert Elz
> Sent: Wednesday, February 19, 2003 5:05 PM
> To: [e-mail]
> Subject: 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.

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

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

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

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

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.

> 
> 
> The description of the offset after Dst doesn't indicate whether that
> 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]].  

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

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

> 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 example is also correct, since "offset" is specified, its relative
to UTC. 

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

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

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


> 
> kre
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg