Re: [Sedate] Warren Kumari's No Objection on draft-ietf-sedate-datetime-extended-10: (with COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Warren,

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I am balloting NoObjection (to a large extent because this is exactly what the
> SEDATE charter calls dfor), but this document fills me with unease.

I’m not sure I understand this concern.

> I agree with Joe Clarke's concerns in the OpsDir around backwards compatibility:
> https://datatracker.ietf.org/doc/review-ietf-sedate-datetime-extended-10-opsdir-telechat-clarke-2023-10-12/
> and
> https://datatracker.ietf.org/doc/review-ietf-sedate-datetime-extended-08-opsdir-lc-clarke-2023-06-12/
> but I don't really know if anything can be done to solve this (other than
> plastering "WARNING: Existing implementations will likely choke and die" all
> over the place).

Implementations of what?
Obviously, don’t feed IXDTF to an RFC 3339 implementation.
If the extensions of IXDTF are not appropriate for an application, don’t use it — you know where to find RFC 3339.

The one update to RFC 3339 reduces the complexity.
Logging should be happening in UTC already, so you now have more license to use Z in place of a not-so-interoperable -00:00.

So the RFC 3339 fix is a net win, and you can avoid the complexity (and additional bulk) of IXDTF by sticking with RFC 3339.

What is the operational impact?

Grüße, Carsten


> I'm also concerned that this will make working with operational logs harder --
> as it is, when 'cat'ing various log files (or looking at logs on various
> network equipment), much of the "meat" of the log is already lost because it
> scrolls off the left side of the screen (or is replaced by [...]).
> 
> Again, much of this seems to be baked into the SEDATE charter, and so I'm
> balloting NoObj, but it is with a feeling of disquiet.
> 
> 
>