[CDNi] RFC8007bis CI/T TimePolicy Extension - LocalTimeWindow and DateLocalTime

[Jay Robertson <[e-mail]>]

Hello everyone,

I am reaching out to you today about an issue regarding the TimePolicy
extension in RFC8007bis, the Control Interface / Triggers 2nd Edition
draft.  Specifically, the area of the proposed standard that I am referring
to is this:
https://datatracker.ietf.org/doc/html/draft-ietf-cdni-ci-triggers-rfc8007bis#name-timepolicy-extension

Some of you may remember that concerns were raised by Kevin Ma and
discussed at IETF 119 regarding DateLocalTime, the abridged form of ISO
8601 that currently defines the format for the start and end times of
LocalTimeWindow.  The concerns raised have prompted us to look more
critically at the need for LocalTimeWindow, which is one of three different
methods to define a TimePolicy for a prepositioning or invalidation trigger.

The LocalTimeWindow is the only TimePolicy defined that allows for
timestamps to be interpreted as absolute times in the local timezone of the
cache server.  The idea behind this is to have a purge job that gradually
executes as the time window is reached in each time zone.

LocalTimeWindow has some significant complexities in terms of specifying,
parsing, and interpreting the time, and appears to be of questionable value
from a use case perspective.  In the interest of time and simplification,
we are considering the removal of this part of the TimeWindow extension for
the following reasons:

   - Local time is not easily defined uniformly.  Countries have
   non-uniform daylight saving time.  Time zones are not always defined on
   hour boundaries.
   - Its purpose can already be achieved through other extensions.
   Executing triggers regionally can be more easily performed by combining the
   TimePolicy extension with the LocationPolicy extension.
   - The removal of LocalTimeWindow obviates the need for DateLocalTime,
   which we can also remove to alleviate the concerns that were raised.
   - Use cases appear to be limited to prepositioning tasks.
   - From a prepositioning perspective, popular objects are typically not
   made available on time zone boundaries.
   - This ignores the realities of tiered delivery models, where cache
   servers in one time zone may populate cache from another time zone.

Does anyone else feel strongly about the need for LocalTimeWindow, or do
you agree with our proposal to simplify the draft by removing this and
DateLocalTime? Please respond to this mailing list at your earliest
convenience, as we plan to publish an updated draft in 2 weeks.

Thanks,
- Jay