Robert, thank you for your review and thank you all for the following discussion. I have entered a Discuss ballot for this document based on my own review (which I think will be straightforward to address). Lars > On Jun 14, 2023, at 00:59, Robert Sparks via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Robert Sparks > Review result: Ready with Issues > > 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 > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > 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". > > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
