Re: [Sedate] [Last-Call] Genart last call review of draft-ietf-sedate-datetime-extended-08

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@ietf.org> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call