[netmod] Re: [Last-Call] Re: Artart last call review of draft-ietf-netmod-rfc6991-bis-16

[Bron Gondwana <[e-mail]>]

On Mon, Oct 21, 2024, at 21:38, Jürgen Schönwälder wrote:
> Thanks for your review, Bron. See my response inline...
> 
> On Sun, Sep 29, 2024 at 09:27:56AM -0700, Bron Gondwana via Datatracker wrote:
> > *Date-Time:*
> > 
> > While the date-time format duplicates the description found in RFC 6021 and
> > later RFC 6991, the construct -00:00 has been identified as being incompatible
> > with the latest ISO8601 by the work in the SEDATE working group.  I would refer
> > you to section 2 of RFC 9557 for the full description and update of RFC 3339
> > which was done there.  I suggest that this document should be updated to align
> > with (and reference) RFC 9557 and deprecate the usage of -00:00; instead using
> > "Z" to mean "local time reference point is unknown" as is common practice. 
> > This will improve future interoperability with ISO8601.
> > 
> > Likewise the same issue occurs with the new "date" format and "time" format.
> 
> This has been discussed in the WG and the conclusion was to not change
> the 'date-and-time' format as it is widely implemented. Note that RFC
> 6020 picked -00:00 as the canonical representation for values in UTC
> with an unknown local time-offset. RFC 9557 now suggests to use Z
> instead. If we change date-and-time to use Z instead of -00:00, then
> existing implementations of 'date-and-time' become non-compliant.
> Hence, we prefer to stick to what we have.
> 
> For the new 'date' and 'time' definitions we can adopt RFC 9557 and
> use Z instead of -00:00. This of course means that UTC values with an
> unknown local time-offset will be reported differently in 'date-and
> time' values and 'date' or 'time' values. Yes, all this is somewhat
> unfortunate. I will update the definitions of 'date' and 'time' to
> follow RFC 9557 but I will not touch 'date-and-time' for now unless
> lets say the IESG decides that alignment with RFC 9557 is more
> important than our concerns about compliance of existing
> implementations generating canonical representations.

Thanks for your responses - sorry I didn't get back to this until nearly at the end of this IETF meeting!

The decision on whether it's more important to try to align everything we can to the more sensible handling of 'Z' and -00:00, or leave things how they are, is beyond my pay grade!  I'll leave it for the IESG to weight the pros and cons.

I do note that the discussion in SEDATE suggested that most everyone is already using Z to mean "it's in UTC but no assertion of physical location" while "+00:00" meant "it happened in this physical part of the earth".

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]