Skip to main content

Date and Time on the Internet: Timestamps with additional information
draft-ietf-sedate-datetime-extended-11

Yes

Francesca Palombini

No Objection

Jim Guichard
(Martin Duke)

Note: This ballot was opened for revision 10 and is now closed.

Francesca Palombini
Yes
Erik Kline
No Objection
Comment (2023-10-16 for -10) Sent
# Internet AD comments for draft-ietf-sedate-datetime-extended-10
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S2.2

* I concur with Lars' DISCUSS point.  Seems best to update or not update
  RFC 3339 section 4.3 ("there is no try" :-).

### S4.1

* Consider a sentence or two at the end that calls out the prohibition
  of "." and ".." from the time-zone-part production trailing comment.
  It seems to my uneducated eye that the ABNF actually allow this, so
  the checking would need to be done separately by implementations?

## Nits

### S1.2

* "UTC was designed to be a useful successor for" ->
  "for which UTC was designed to be a useful successor"

### S2.1

* "always was" -> "was always" or even just "has been"
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2023-10-18 for -10) Sent
Thanks for this easy-to-read document.

## COMMENTS

### Section 3.2, misused 2119 keyword

                                                    See
   [BCP178] for a discussion about the danger of experimental keys
   leaking out to general production and why that MUST be prevented.

That MUST is far afield from what RFC 2119 thinks it should be used for. Seems like it should be "must".

### Section 3.4 examples are silent on handling the "critical" mark

Section 3.4 has two sets of examples. Each set is a pair, with the same timestamp, but in one the tag is marked critical and in the other, it isn't. The text doesn't say anything about the difference in handling the critical vs. non-critical versions. I can see why you'd want the two versions -- IF you were going to use them in the explanatory text, to illuminate the use of the critical mark. But you don't. Seems like you should either talk about the difference in how they're handled or just supply one version.

## LESS-THAN-NITS

Note that AFAICT every instance of “note that” in this document could be deleted without loss of clarity, but this is purely a personal style matter. (OK the one in §3.4 does serve the purpose of letting the sentence not begin with "-00:00" which would be a little jarring.)
Paul Wouters
No Objection
Comment (2023-10-18 for -10) Sent
I very strongly agree with Warren's ballot on this and his reasoning to ballot No Objection.

Additionally, I am puzzled by this Security Consideration:

     only such extensions can be employed that have a defined resolution of such inconsistent data.

So what about this example:

      2022-07-08T00:14:07+01:00[Australia/Brisbane]

Clearly Brisbane does not have the +01:00 UTC offset. What is the "defined resolution" for this case?
Roman Danyliw
No Objection
Comment (2023-10-18 for -10) Sent
Thank you to Kyle Rose for the SECDIR review.

** Section 6.  Would there be any keys that should not be accepted by the DE?  As I read it now, just about any temporary registration would be acceptable.

Editorial
-- Section 1.  Editorial (?)

This is a pressing issue for applications that handle each instant
   with an associated time zone name

What does “instant” mean here?  Is that a term of art, or should be be “instance”?

-- Editorial.  Consider using consistent terminology in referencing implementations of this specification.   Section 2.1 uses “Programs”.  Section 3.1 uses “Applications”. Section 3.2 uses “Implementations”.
Warren Kumari
No Objection
Comment (2023-10-17 for -10) Sent
I am balloting NoObjection (to a large extent because this is exactly what the SEDATE charter calls dfor), but this document fills me with unease. 

I agree with Joe Clarke's concerns in the OpsDir around backwards compatibility:
https://datatracker.ietf.org/doc/review-ietf-sedate-datetime-extended-10-opsdir-telechat-clarke-2023-10-12/
and
https://datatracker.ietf.org/doc/review-ietf-sedate-datetime-extended-08-opsdir-lc-clarke-2023-06-12/
but I don't really know if anything can be done to solve this (other than plastering "WARNING: Existing implementations will likely choke and die" all over the place).

I'm also concerned that this will make working with operational logs harder -- as it is, when 'cat'ing various log files (or looking at logs on various network equipment), much of the "meat" of the log is already lost because it scrolls off the left side of the screen (or is replaced by [...]).

Again, much of this seems to be baked into the SEDATE charter, and so I'm balloting NoObj, but it is with a feeling of disquiet.
Zaheduzzaman Sarker
No Objection
Comment (2023-10-17 for -10) Not sent
No objection other than supporting Lars's Discuss.
Éric Vyncke
No Objection
Comment (2023-10-17 for -10) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-sedate-datetime-extended-10

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Mark McFadden for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. 

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Section 1.2 (mostly nits)

The example of New York time would benefit of adding "in the USA" and "in 2023" (the latter would allow a better aging -- who knows ?).

Should ICAO be expanded ?

Should "San Francisco" be qualified as in "San Francisco, California" ?

## Backward compatibility

As I am not familiar with RFC 3339, I wonder whether the new syntax could break some legacy RFC 3339 implementations (including parsing libraries). Were there some tests ?
Lars Eggert Former IESG member
(was Discuss) No Objection
No Objection (2023-10-23) Sent for earlier
# GEN AD review of draft-ietf-sedate-datetime-extended-10

CC @larseggert

Thanks to Robert Sparks for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/v8WWSDLRM3T-Taai4w6XCAqWFJg).

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `handicapped`; alternatives might be `broken`, `damaged`, `defective`,
   `deformed`, `impaired`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Reference `[RFC1305]` to `RFC1305`, which was obsoleted by `RFC5905` (this may
be on purpose).

Reference `[RFC2822]` to `RFC2822`, which was obsoleted by `RFC5322` (this may
be on purpose).

### Grammar/style

#### Section 1.2, paragraph 10
```
fic UTC offset, e.g. +08:45, and serialized using as its name the same numer
                                 ^^^^^^^^^^
```
Do not mix variants of the same word ("serialize" and "serialise") within a
single text.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
Martin Duke Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2023-10-19 for -10) Sent
Hi,

Thanks for this document.  I only have one question/comment:

(1) p 7, sec 2.3.  Notes

   Note also that the fact that [ISO8601:2000] and later do not allow
   -00:00 as a local offset reduces the level of interoperability that
   can be achieved in using this feature; the present specification
   however does not formally deprecate this syntax.  With the update to
   RFC 3339, the local offset Z can be used in its place.

I was wonder why this is "can be used" and not "SHOULD be used", or if that is too strong then "should be used".  I.e., I appreciate why we may want to still allow the old format now, but shouldn't this document push a little harder towards getting everyone to use the Z format?

Regards,
Rob