Hi Robert, Thank you for this review. Please see my comments on individual issues below. > On 2023-06-13, at 23: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". Yes. I would expect the Designated Expert to discuss names like these with the registrant, and either arrive at a better name, or learn a good reason why the name is great as proposed. It doesn’t make too much sense to put policy (the name MUST look nice :-) into mechanism, when the policy isn’t defined (and not really definable). For names starting with an underscore (experimental names), “_——” is fine; if the experiment involves Enterprise-class spaceships, that may actually be a good name. > 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. If you have a specific restriction in mind, I’d sure like to know about it. > 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 > ".-.+..+.-."? These are POSIX file names, and I’d infer that “.” and “..” are excluded because they could be misinterpreted as pointers to the current and enclosing directory, respectively. “.-.+..+.-.” is fine, assuming that style issues will be addressed somewhere else. See https://data.iana.org/time-zones/theory.html, which also has the rather old-fashioned restriction that time-zone-parts should be 14 characters or less — of course not all of that prose description could be molded into ABNF. > And to make sure - you want to allow more than one / in the time-zone-name > production, such as America/Chicago/Canaryville? https://data.iana.org/time-zones/theory.html gives the specific example: America/Indiana/Petersburg > Editorial Nits: > > At scope, you say "way to attach any additional information". I suggest "way to > attach additional information" is enough. I agree. > 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). I don’t think that it helps to remove information from this definition. The main point here is that UTC is something very specific, the definition of which changed over time (and actually started only in 1972). (And that GMT is no longer a valid name for UTC.) > At the definition of timestamp, I quibble with using "unambiguous". This > document isn't attempting to address disambiguating which 1:30 Very much so, actually. IXDTFs are really RFC 3339 timestamps inside. > 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? RFC 3339 says [1]: Timestamp This term is used in this document to refer to an unambiguous representation of some instant in time. [1]: https://www.rfc-editor.org/rfc/rfc3339.html#section-2 We could divulge that the definition is adapted from RFC 3339, but I don’t see a strong need to do that. > 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. I agree. > 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". I agree. Except for the last item that will need more work, I have put a proposal for editorial changes into https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull/44 Grüße, Carsten -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
