On 6/14/23 3:22 AM, Carsten Bormann wrote:
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.
Just making sure you weren't really intending to have symmetry with how
values are produced (which doesn't allow strings like "a----"). It
doesn't bother me, but I'm curious, _why_ do the keys have a different
structure than the values beyond the ability to start with an underscore
and otherwise starting with [a-z]? (Consider saying why you have those
restrictions in the document). Also look at the last sentence of the
second paragraph in 3.1 and see if "items" should be more specific.
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.
Are the guidelines there effectively the actual (normative) requirements
on the names?
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
ack
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.)
Maybe saying that explicitly is better than trying to get the reader to
infer it from such a small synopsis of history. And I wasn't suggesting
removing the sentence about GMT.
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.
I yield.
(I'll save my quibble for some future argument that is opening 3339 up
more thoroughly.)
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
those lgtm
Grüße, Carsten
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
