Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03

[Andy Bierman <[e-mail]>]

On Tue, Jan 28, 2014 at 8:08 AM, David Spakes <[e-mail]> wrote:

> On Tue, 28 Jan 2014, Ladislav Lhotka wrote:
>
> > >>  typedef timezone-name {
> > >>    type string;
> > >>    description
> > >>     "A timezone name as used by the Time Zone Database, sometimes
> > >>      referred to as the 'Olson Database'.";
> > >>    reference
> > >>     "RFC 6557: Procedures for Maintaining the Time Zone Database";
> > >>  }
> > >
> > > I support this solution.
> > >
> > > However, I think we need to explain in the description text of the
> > > timezone-name typedef that servers will restrict the valid values for
> > > this type to whatever they support, and that how clients can learn
> > > which values are valid is out of scope for this document.
> >
> > A client also needs to be able to learn the corresponding UTC offsets
> > and DST rules.
> >
> > I don't have a strong opinion here but I wonder whether the benefits
> > of the string type outweigh the damage to interoperability. My concern
> > is that a string might be vulnerable not only to political, but also
> > marketing pressures.
>
>
> If the client has a way to view the list of strings recognized by the
> server together with their corresponding UTC offsets and DST changes,
> then we should be able to lay to rest any and all concerns about how
> political and marketing pressures affect the implementation of
> individual devices.
>
> I made a proposal a little over a week ago that is relevant.  No one
> commented on it at that time, but maybe it should be discussed now.
> Here it is again.
>
>
> On Fri, 17 Jan 2014, David Spakes wrote:
>
> > If the client needs to be able to see the list of strings that the
> > server is actually using, then the client should not reach out to the
> > TZ Database; it should consult the server.  In addition to the typedef,
> > the document should define a config false list of strings that the
> > server actually supports.
>
>
> Here is basically what I had in mind:
>
>   list known-timezones {
>     config false;
>
>     leaf name {
>       type timezone-name;
>     }
>     leaf utc-offset {
>       // whatever type is appropriate
>     }
>     leaf valid-time {
>       type uint32 {
>         range "0 .. 365";
>       }
>       description
>         "The number of days this advice is expected to remain valid.";
>     }
>   }
>
>
> To prepare to configure a device, a client would retrieve the list.
> A graphical-based client could use this information to populate a
> choice widget from which a human operator could select the desired
> value.  A non-interactive client could validate a predetermined
> selection or automatically make a choice based on the utc-offset.
>
> The valid-time would be used to set a timer in the client.  When the
> timer fires, it's time to review the choice and potentially reconfigure
> the device.  The client should retrieve the list again from the device
> in order to update the choice.  For countries with a predetermined date
> to switch between standard and daylight savings time, the valid-time
> would indicate the number of days until the next switch.  If a country
> (or state, or other municipality) chooses to modify the DST scheduled
> (as the United States did a couple of years ago), the valid-time would
> indicate the date when such a schedule change is expected.  If a date
> is unknown to the device, it could set the value to zero, which means
> "check back often".  In a region where there is no change for DST, the
> value would remain 365 every time the information is retrieved.
>
>

In order to justify all this extra work on the client and server, it would
help to understand the impact that timezone interoperability problems
are having on real deployments.

IMO the real TZ database is going to match the server values for
over 99.5% of the string values.  A few corner-cases are not worth
worrying about.




> -dss
>
>
Andy