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) Issue: 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".