Re: [netmod] AD review of draft-ietf-netmod-rfc6991-bis-15

[Jürgen Schönwälder <[e-mail]>]

On Tue, Apr 16, 2024 at 10:08:09AM -0700, Mahesh Jethanandani wrote:
> Hi Jürgen,
> 
> It appears that Brian and you had made progress on the other thread related to IPv6 zone definition. Are there any outstanding issues that need to be resolved?
> 
> What is the plan to submit an updated version of the document?
>

I had to take a fresh look at things and I think the discussion around
zones of IP addresses is moving to a conclusion. That said, I believe
we are not done with the work related to dates, times, and durations.
What we have is not really good and also in conflict with newer work
that came out of the sedate WG and has passed IESG approval (I think).
Here is a not so short summary (I have even more details since I did
take a look into what standard libraries of various system programming
languages offer).

* date-and-time, date, time

  For time zones, we used to have the canonical format +00:00 for
  systems in UTC located and a known timezone offset of 00:00. For
  systems in UTC with an unknown timezone offset, the canonical format
  has been -00:00. This was based on RFC 3339 which introduced the
  -00:00 which is not strictly allowed by the ISO 8601 format.

  The sedate work is updating RFC 3339 recommending against the use of
  the -00:00 notation (since it is not conforming to ISO 8601) and
  instead suggests that Z is used for systems in UTC with an unknown
  timezone offset.

  The question is now how we deal with this non-backwards compatible
  change of RFC 3339 that apparently got approved by the IESG and
  hence there is believe that the Internet won't break based on the
  argument that using Z instead of -00:00 is already common practice.
  If so, do we simply align our definition with the updated version of
  RFC 3339?  Or do we go an deprecate date-and-time and create a new
  definition (and then we deal with the updates of all affected
  modules over time)?

  Note that this also affects the newly defined zoned types date and
  time.

  Looking forward, we may even want to consider supporting formats
  that allow for timezone names instead of only static numeric
  offsets. So another option might be to leave date-and-time as is
  (potentially deprecating it once there is a better replacement) and
  to start a new module, say ietf-chrono, that defines new date and
  time related types that are aligned with the updated RFC 3339 and
  the work done by the sedate working group to enable the use of time
  zone names.

* nanoseconds, microseconds, milliseconds, seconds, minutes, hours

  There was some discussion around the choice of signed vs unsigned
  base types and the choice between 32 and 64 bits. I have
  investigated a bit what standard libraries of system programming
  languages do and I concluded that using signed integer types
  dominates and that we should use 64-bit types for everything up
  to and including seconds (and not offer 32-bit alternatives).

  It is easy to range restrict to just positive numbers and it is
  also easy to range restrict to use less than 64 bits.

  If we would start a new module for date and time types, then these
  definitions should likely be moved there as well.

I believe to have proper types for data and time and durations, it is
best to factor this work out into a separate effort. This gives us
more freedom to do things right without any harm on backwards
compatibility (we would not change date-and-time, except perhaps
adding a warning note that use of -00:00 is getting discouraged).

/js

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany