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 General Area Review Team (Gen-ART) (genart)
Deadline 2023-06-15
Requested 2023-06-01
Authors Ujjwal Sharma , Carsten Bormann
I-D last updated 2023-06-13
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 Robert Sparks
State Completed
Request Last Call review on draft-ietf-sedate-datetime-extended by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 08 (document currently at 11)
Result Ready w/issues
Completed 2023-06-13
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-sedate-datetime-extended-08
Reviewer: Robert Sparks
Review Date: 2023-06-13
IETF LC End Date: 2023-06-15
IESG Telechat date: Not scheduled for a telechat

Summary: Essentially ready for publication as a Proposed Standard RFC, but with
issue to consider before full IESG review (Ready with Issues)


The ABNF for suffix-key allow productions like "_----", "a---", and "a----b".
I'm guessing at intent, but my guess is that you essentially wanted the same
production you allow for the suffix values, but you want to restrict that to
the set of values that start with either _ or [a-z]. If my guess is correct, I
can help construct alternate ABNF.

I have a similar question about time-zone-part where you in a comment rule out
the two productions "." and "..". Should you say anything about 14 dots? Or

And to make sure - you want to allow more than one / in the time-zone-name
production, such as America/Chicago/Canaryville?

Editorial Nits:

At scope, you say "way to attach any additional information". I suggest "way to
attach additional information" is enough.

The definition of UTC has a a short bit of history in it that is interesting,
but unnecessary for this document. Consider removing from "From 1972" to the
end of the first paragraph of the definition. (If you want to point to history,
choose a rich informational reference perhaps).

At the definition of timestamp, I quibble with using "unambiguous". This
document isn't attempting to address disambiguating which 1:30 am you mean when
there were two of them on a DST end day. How would the document suffer if you
simply dropped the word from the definition?

In the second paragraph of section 2 - I get lost in "former" and "latter" (I'm
not sure the text is pointing where it intends to point). Please consider just
directly stating the convention you are talking about instead.

The section heading names under section 3 are not particularly helpful, and the
text doesn't quite follow the intended structure that I think inspired them.
It's not really clear that the section does everything that the first sentence
of section 3 says it will. Please consider a gentle restructuring of the
outline into something like "Format of extended information","Registering
extended information tags", "Requirements for producing extension tags",
"Requirements for consuming extension tags".