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

[Carsten Bormann <[e-mail]>]

On 2024-04-18, at 15:05, Jürgen Schönwälder <[e-mail]> wrote:
> 
>  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.

Correct.
(Note the word “recommending”.)

>  The question is now how we deal with this non-backwards compatible
>  change of RFC 3339

I’m not an authority on the term “non-backwards compatible”, but we have been very careful to point out that -00:00 is less interoperable, hence deprecated, but not suddenly disallowed.  So if -00:00 is interoperable in your ecosystem, you can continue to use it.  (You should probably add a note that it is not compatible with other uses of RFC 3339, which already was the case even before we wrote up this fact.)

I think 6991bis already is compatible with the other observation in Section 2.2 of RFC-9557-to-be:

> … "+00:00", which implies that UTC is the preferred reference point …

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

What do YANG implementations do today?
How do they handle the fact that RFC 3339 implementations that they may be using may have trouble with -00:00?
If this is all unproblematic, I don’t see a need to align with the new recommendation in the updated RFC 3339.

(Note that the answer to my question also is relevant for the YANG-CBOR stand-in mechanism [1], which works best if the mapping is deterministic, and therefore currently would produce -00:00 for a timezone-free timestamp.)

[1] https://www.ietf.org/archive/id/draft-bormann-cbor-yang-standin-00.html#name-ietf-yang-types-tag-1-date-

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

There are too many modules that use the existing type, adding a choice sounds like a way to create busywork and ultimately interoperability failures.

Grüße, Carsten