Skip to main content

Last Call Review of draft-ietf-sedate-datetime-extended-08

Request Review of draft-ietf-sedate-datetime-extended
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2023-06-15
Requested 2023-06-01
Authors Ujjwal Sharma , Carsten Bormann
I-D last updated 2023-06-12
Completed reviews Secdir Last Call review of -08 by Kyle Rose (diff)
Genart Last Call review of -08 by Robert Sparks (diff)
Opsdir Last Call review of -08 by Joe Clarke (diff)
Opsdir Telechat review of -10 by Joe Clarke (diff)
Assignment Reviewer Joe Clarke
State Completed
Request Last Call review on draft-ietf-sedate-datetime-extended by Ops Directorate Assigned
Posted at
Reviewed revision 08 (document currently at 11)
Result Has issues
Completed 2023-06-12
I have been tasked to review this document on behalf of the OPS DIR.  Overall,
I struggled with this, and I don't know that "Has Issues" is the right result. 
The document is well-written and clear (and let's face it, time is hard).  But
as an operator, the backwards compatibility didn't resonate with me.  I realize
there is a bit of chicken vs. egg here in terms of standardizing the new format
before tooling will use it, but I think this could cause some incompatibility
issues when you consider something like this:

from datetime import datetime
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid isoformat string: '2022-07-08T00:14:07Z[!Europe/London]'

Until language libraries are updated for this, generators and consumers will be
out of sync.  And let's face it: people don't always move to the latest version
of their favorite language or libraries.

So unless I'm missing something (and I might very well be), I think this
document would benefit from a section on migration guidance.  Moreover, what
about some thought for some strptime/strftime format symbols for this to aim
for language consistency?  I know this might not be the canonical place, but
given the Java references it seems like a recommendation might be acceptable.

On the smaller side, I think Section 5 should be baked into Section 3 to
introduce the u-ca notation before you use it in examples.