Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period
draft-ietf-cbor-time-tag-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-03-25
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2024-01-26
|
12 | Gunter Van de Velde | Request closed, assignment withdrawn: Carlos Martínez Last Call OPSDIR review |
2024-01-26
|
12 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2024-01-10
|
12 | Christian Amsüss | Added to session: interim-2024-cbor-01 |
2023-11-16
|
12 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2023-11-16
|
12 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Christopher Wood was marked no-response |
2023-11-13
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2023-11-13
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2023-11-13
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2023-11-08
|
12 | (System) | RFC Editor state changed to EDIT |
2023-11-08
|
12 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2023-11-08
|
12 | (System) | Announcement was received by RFC Editor |
2023-11-08
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2023-11-07
|
12 | (System) | IANA Action state changed to In Progress |
2023-11-07
|
12 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2023-11-07
|
12 | Cindy Morgan | IESG has approved the document |
2023-11-07
|
12 | Cindy Morgan | Closed "Approve" ballot |
2023-11-07
|
12 | Cindy Morgan | Ballot approval text was generated |
2023-11-07
|
12 | (System) | Removed all action holders (IESG state changed) |
2023-11-07
|
12 | Francesca Palombini | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2023-11-07
|
12 | Murray Kucherawy | [Ballot comment] Thanks to Thomas Fossati for the ARTART review. And thanks for the IANA Considerations fix. |
2023-11-07
|
12 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss |
2023-11-06
|
12 | Christian Amsüss | Added to session: IETF-118: cbor Tue-1430 |
2023-10-30
|
12 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2023-10-30
|
12 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-10-30
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2023-10-30
|
12 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-12.txt |
2023-10-30
|
12 | Jenny Bui | Forced post of submission |
2023-10-30
|
12 | (System) | Request for posting confirmation emailed to previous authors: Ben Gamari , Carsten Bormann , Henk Birkholz |
2023-10-30
|
12 | Carsten Bormann | Uploaded new revision |
2023-10-26
|
11 | (System) | Changed action holders to Carsten Bormann, Ben Gamari, Henk Birkholz (IESG state changed) |
2023-10-26
|
11 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2023-10-26
|
11 | Robert Wilton | [Ballot comment] Moving to no-obj based on reply for Carsten. |
2023-10-26
|
11 | Robert Wilton | [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss |
2023-10-26
|
11 | Zaheduzzaman Sarker | [Ballot Position Update] Position for Zaheduzzaman Sarker has been changed to No Objection from No Record |
2023-10-26
|
11 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this specification. No objection from TSV point of views but supporting Murray's discuss on clarification of IANA registry creation. |
2023-10-26
|
11 | Zaheduzzaman Sarker | Ballot comment text updated for Zaheduzzaman Sarker |
2023-10-25
|
11 | Murray Kucherawy | [Ballot discuss] Section 7.2 establishes a new IANA registry using "a combination of "Expert Review" and "RFC Required" as the Registration Procedure". How are they … [Ballot discuss] Section 7.2 establishes a new IANA registry using "a combination of "Expert Review" and "RFC Required" as the Registration Procedure". How are they combined? Is it either-or? Do different ranges have different policies? Does the applicant get to choose? Does the designated expert get to choose? |
2023-10-25
|
11 | Murray Kucherawy | [Ballot comment] Thanks to Thomas Fossati for the ARTART review. |
2023-10-25
|
11 | Murray Kucherawy | [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy |
2023-10-25
|
11 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2023-10-25
|
11 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2023-10-25
|
11 | Andrew Alston | [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston |
2023-10-25
|
11 | Robert Wilton | [Ballot discuss] Hi, Thanks for this document, I have a few "discuss" level comments: Moderate level comments: (1) p 0, sec The Concise Binary … [Ballot discuss] Hi, Thanks for this document, I have a few "discuss" level comments: Moderate level comments: (1) p 0, sec The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. My main concern here is the risk that introducing these new time encodings could end reducing interoperability. My initial reading is that these new types are more flexible, contain more information, and hence require more code to parse and understand than say the tag 1 type, and hence may not be so widely understood and used by implementations. Hence, please can the authors consider whether there should be a recommendation to use time type 1 in preference, and only use the extended time types where required? Or conversely, encourage everyone to move to a particular variant of the new extended time type. (2) Related to my previous comment, I have a question about normalization or canonicalization. The new extended time type allows the same time to be represented in multiple different ways (e.g., int, binary float, decimal float, split secs + fraction). Does any guidance need to be given if canonicalization is required? (3) p 12, sec 4. Duration Format Semantically, they do not measure the time elapsed from a given epoch, but from the start to the end of (an otherwise unspecified) interval of time. Are any of the fields defined in etime-detailed not appropriate for a duration, and if so should they be listed and what should a receiver do if they receive them? Or is the only rational choice here that is has to be down to the application to decide how to handle this case? Either way, is any additional text needed here? |
2023-10-25
|
11 | Robert Wilton | [Ballot comment] Minor level comments: (4) p 13, sec 5. Period Format Period = #6.1003([ start: ~Etime / null end: … [Ballot comment] Minor level comments: (4) p 13, sec 5. Period Format Period = #6.1003([ start: ~Etime / null end: ~Etime / null ? duration: ~Duration / null ]) If the third array element is not given, the duration element is null. Exactly two out of the three elements must be non-null, this can be somewhat verbosely expressed in CDDL as: I found it harder (but not impossible) to understanding the intended encoding here. Also, rather than allowing duration to be null, or missing (i.e., len 2 array), would it better to choose just one of these encodings, or otherwise do you need to consider canonicalization of start/end periods? Perhaps splitting this into two paragraphs would be easier to read/explain. E.g., A period can be represented by a start and end time, in which case it is represented as an array of two elements. Alternatively, a period can be represented as a start time with duration or an end time with duration. This is represented as an array of 3 elements where either the start or end time MUST be set to null. Regards, Rob |
2023-10-25
|
11 | Robert Wilton | [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton |
2023-10-24
|
11 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2023-10-24
|
11 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2023-10-24
|
11 | Éric Vyncke | [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-cbor-time-tag-11 Thank you for the work put into this document. I am trusting the responsible AD … [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-cbor-time-tag-11 Thank you for the work put into this document. I am trusting the responsible AD for the CDDL specifications, please also note that I am not a time specialist. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Barry Leiba for the shepherd's minimalist write-up including the WG consensus and the justification of the intended status. Other thanks to Qin Wu, the IoT directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-cbor-time-tag-10-iotdir-telechat-wu-2023-10-17/ (and I have read the follow-up email discussion) I hope that this review helps to improve the document, Regards, -éric # COMMENTS ## Section 2 What is "TAI" ? ## Section 3 As non native English speaker, I find this clause unclear: `these keys are "elective", as the extended time is still usable if an implementation elects not to implement them` I.e., how can it be usable if the implementation does not support it ? Is it because the added information is not critical ? ## Section 3.3 Should there be a reference for Haskell time ? ## Section 3.4 Please add an informative reference to NTP. More important, "GPS" is a specific system out of the USA. Please use "GNSS" as it also covers non-USA satellite systems such as Galileo. |
2023-10-24
|
11 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2023-10-23
|
11 | Erik Kline | [Ballot comment] # Internet AD comments for draft-ietf-cbor-time-tag-11 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 … [Ballot comment] # Internet AD comments for draft-ietf-cbor-time-tag-11 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 ### S4 * With this definition of Duration, it seems like implementers might need to support a duration with an accompanying critical Time Zone Hint, is that correct? Seems ... odd, but I understand the desire for de-duplication. |
2023-10-23
|
11 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2023-10-23
|
11 | Thomas Fossati | Request for Last Call review by ARTART Completed: Ready. Reviewer: Thomas Fossati. Review has been revised by Thomas Fossati. |
2023-10-23
|
11 | Paul Wouters | [Ballot comment] NITS: TAI is never expanded - expand on first use? At least for me this was a new term, unlike UTC. But perhaps … [Ballot comment] NITS: TAI is never expanded - expand on first use? At least for me this was a new term, unlike UTC. But perhaps it is obvious for implementers in this space. The present document Use "This document" therefore is rendered by the surrogate notation seen here in the plain-text rendition. "here" is a bit weird when I'm reading the HTML version. Can't you just write 2^xx as an example ? The security considerations of RFC 8949 apply A link is missing here. |
2023-10-23
|
11 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2023-10-23
|
11 | Robert Sparks | Request for Last Call review by GENART Completed: Ready. Reviewer: Robert Sparks. Sent review to list. |
2023-10-23
|
11 | Roman Danyliw | [Ballot comment] ** Section 2. For example, map keys could be registered for direct representations of natural platform time formats. What are “natural … [Ballot comment] ** Section 2. For example, map keys could be registered for direct representations of natural platform time formats. What are “natural platform time formats”? ** Section 3. The map must contain exactly one unsigned integer key that specifies the "base time", and may also contain one or more negative integer or text-string keys, which may encode supplementary information. Should a normative MUST and MAY be used here? ** Section 8. Time, of course, has significant security considerations; these include the exploitation of ambiguities where time is security relevant (e.g., for freshness or in a validity span) or the disclosure of characteristics of the emitting system (e.g., time zone, or clock resolution and wall clock offset). Recommend citing the Security Considerations of draft-ietf-sedate-datetime-extended. The text there covers a number of the topics mentioned above. |
2023-10-23
|
11 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2023-10-22
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2023-10-22
|
11 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-11.txt |
2023-10-22
|
11 | Carsten Bormann | New version accepted (logged-in submitter: Carsten Bormann) |
2023-10-22
|
11 | Carsten Bormann | Uploaded new revision |
2023-10-21
|
10 | Francesca Palombini | Ballot has been issued |
2023-10-21
|
10 | Francesca Palombini | [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini |
2023-10-21
|
10 | Francesca Palombini | Created "Approve" ballot |
2023-10-21
|
10 | Francesca Palombini | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2023-10-21
|
10 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2023-10-17
|
10 | Qin Wu | Request for Telechat review by IOTDIR Completed: Ready with Nits. Reviewer: Qin Wu. Sent review to list. Submission of review completed at an earlier date. |
2023-10-17
|
10 | Qin Wu | Request for Telechat review by IOTDIR Completed: Ready with Nits. Reviewer: Qin Wu. |
2023-10-17
|
10 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2023-10-17
|
10 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-cbor-time-tag-10. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-cbor-time-tag-10. If any part of this review is inaccurate, please let us know. IANA has questions about the second and third actions requested. IANA understands that, upon approval of this document, there are three actions which we must complete. First, in the CBOR Tags registry in the Concise Binary Object Representation (CBOR) Tags registry group located at: https://www.iana.org/assignments/cbor-tags/ three early registrations will have their references changed to [ RFC-to-be ] as follows: Tag: 1001 Data Item: map Semantics: extended time Reference: [ RFC-to-be ] Tag: 1002 Data Item: map Semantics: duration Reference: [ RFC-to-be ] Tag: 1003 Data Item: array Semantics: period Reference: [ RFC-to-be ] We note that the "Data Item" entry for Tag 1003 is changed from "map" to "array." Second, a new registry is to be created called the Timescales registry. The new registry is to be located in the Concise Binary Object Representation (CBOR) Tags registry group located at: https://www.iana.org/assignments/cbor-tags/ The new registry will be managed via Expert Review AND RFC Required as defined in [RFC8126]. Each assignment in the registry will consist of a timescale name (a sequence of uppercase ASCII characters and digits, where a digit may not occur at the start: [A-Z][A-Z0-9]*), a value (CBOR unsigned integer, uint), and brief description of the semantics, and a specification reference (RFC). IANA Question -> What are the minimum and maximum values for this registry? There are initial registrations in the new registry as follows: Timescale Value Semantics Reference ----------+-----+----------+------------- UTC 0 UTC with POSIX Epoch [ RFC-to-be ] TAI 1 TAI with PTP Epoch [ RFC-to-be ] Third, a new registry is to be created called the Time Tag Map Keys registry. The new registry is to be located in the Concise Binary Object Representation (CBOR) Tags registry group located at: https://www.iana.org/assignments/cbor-tags/ The new registry will be managed via Specification Required as defined in [RFC8126]. Each assignment in the new registry will consist of a map key value (CBOR integer, int), a brief description of the semantics, and a specification reference (RFC). IANA Question -> What are the minimum and maximum values for this registry? There are initial registrations in the new registry as follows: Value Semantics Reference -----+----------+----------------- -18 attoseconds [ RFC-to-be ] -15 femtoseconds [ RFC-to-be ] -12 picoseconds [ RFC-to-be ] -11 IXDTF Suffix Information (elective) [ RFC-to-be ], [IXDTF] -10 IXDTF Time Zone Hint (elective) [ RFC-to-be ], [IXDTF] -9 nanoseconds [ RFC-to-be ] -8 Guarantee [ RFC-to-be ] -7 Uncertainty [ RFC-to-be ] -6 microseconds [ RFC-to-be ] -5 Offset-Scaled Log Variance [ RFC-to-be ] -4 Clock Accuracy [ RFC-to-be ] -3 milliseconds [ RFC-to-be ] -2 Clock Class [ RFC-to-be ] 1 Base Time value as in CBOR Tag 1 [RFC8949] [ RFC-to-be ] 4 Base Time value as in CBOR Tag 4 [RFC8949] [ RFC-to-be ] 5 Base Time value as in CBOR Tag 5 [RFC8949] [ RFC-to-be ] 10 IXDTF Time Zone Hint (critical) [ RFC-to-be ], [IXDTF] 11 IXDTF Suffix Information (critical) [ RFC-to-be ], [IXDTF] We understand that these are the only actions required to be completed upon approval of this document. NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2023-10-16
|
10 | Ines Robles | Request for Telechat review by IOTDIR is assigned to Qin Wu |
2023-10-16
|
10 | Ines Robles | Assignment of request for Telechat review by IOTDIR to Jaime Jimenez was rejected |
2023-10-15
|
10 | Ines Robles | Request for Telechat review by IOTDIR is assigned to Jaime Jimenez |
2023-10-14
|
10 | Éric Vyncke | Requested Telechat review by IOTDIR |
2023-10-12
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christopher Wood |
2023-10-12
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2023-10-12
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2023-10-11
|
10 | Francesca Palombini | Placed on agenda for telechat - 2023-10-26 |
2023-10-09
|
10 | Thomas Fossati | Request for Last Call review by ARTART Completed: Ready with Issues. Reviewer: Thomas Fossati. Sent review to list. |
2023-10-07
|
10 | Barry Leiba | Request for Last Call review by ARTART is assigned to Thomas Fossati |
2023-10-07
|
10 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2023-10-07
|
10 | Cindy Morgan | The following Last Call announcement was sent out (ends 2023-10-21): From: The IESG To: IETF-Announce CC: barryleiba@computer.org, cbor-chairs@ietf.org, cbor@ietf.org, draft-ietf-cbor-time-tag@ietf.org, francesca.palombini@ericsson.com … The following Last Call announcement was sent out (ends 2023-10-21): From: The IESG To: IETF-Announce CC: barryleiba@computer.org, cbor-chairs@ietf.org, cbor@ietf.org, draft-ietf-cbor-time-tag@ietf.org, francesca.palombini@ericsson.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period) to Proposed Standard The IESG has received a request from the Concise Binary Object Representation Maintenance and Extensions WG (cbor) to consider the following document: - 'Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2023-10-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949 defines two tags for time: CBOR tag 0 (RFC3339 time as a string) and tag 1 (Posix time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for duration and time period. It is intended as the reference document for the IANA registration of the CBOR tags defined. // The present version (-10) addresses comments and WG discussion // during the AD review. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cbor-time-tag/ No IPR declarations have been submitted directly on this I-D. |
2023-10-07
|
10 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2023-10-07
|
10 | Francesca Palombini | Last call was requested |
2023-10-07
|
10 | Francesca Palombini | Last call announcement was generated |
2023-10-07
|
10 | Francesca Palombini | Ballot approval text was generated |
2023-10-07
|
10 | Francesca Palombini | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2023-10-07
|
10 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2023-10-07
|
10 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-10-07
|
10 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-10.txt |
2023-10-07
|
10 | Carsten Bormann | New version accepted (logged-in submitter: Carsten Bormann) |
2023-10-07
|
10 | Carsten Bormann | Uploaded new revision |
2023-10-03
|
09 | Francesca Palombini | Expecting at least one update following AD review and before IETF Last Call |
2023-10-03
|
09 | (System) | Changed action holders to Carsten Bormann, Ben Gamari, Henk Birkholz (IESG state changed) |
2023-10-03
|
09 | Francesca Palombini | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2023-10-03
|
09 | Francesca Palombini | AD review posted: https://mailarchive.ietf.org/arch/msg/cbor/XokBqX3rHiE5kJoYJIvQM6_XaT0/ |
2023-10-03
|
09 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2023-10-03
|
09 | Francesca Palombini | IESG state changed to AD Evaluation from Publication Requested |
2023-10-03
|
09 | Francesca Palombini | Ballot writeup was changed |
2023-08-23
|
09 | Barry Leiba | ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did … ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? The document has broad agreement from the active working group. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? There are early implementations, though they are not listed. The document is expected to get wide adoption. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. There has been coordination with the SEDATE working group and its document draft-ietf-sedate-datetime-extended. This document is ready to proceed, but there is still a normative reference to the SEDATE document. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? N/A 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. As a product of the CBOR working group, the document has been reviewed by the CBOR experts. There is some simple ABNF in it, which does not need expert review. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? None identified. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The document is aimed at Proposed Standard, providing standards-track guidance on CBOR time tags and an anchor for IANA registrations. This is set in the datatracker after the working group decided to go for Standards Track (it was originally planned as Informational). 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes, and N/A. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) N/A 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? IEEE 1588-2008, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems" requires payment or subscription. It is used in other IETF documents. JCGM 100:2008, "Evaluation of measurement data — Guide to the expression of uncertainty in measurement" is a product of the Joint Committee for Guides in Metrology. It is freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. No. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? draft-ietf-sedate-datetime-extended is in the SEDATE working group's processing. It has completed working group last call and is in the hands of the IESG. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No. 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The IANA Considerations section is clear and complete. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. Two new registries are created, and each will need a designated expert. It is reasonable to ask the authors of this document to serve in that role. Explanations and instructions are clear. |
2023-08-23
|
09 | Barry Leiba | Responsible AD changed to Francesca Palombini |
2023-08-23
|
09 | Barry Leiba | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2023-08-23
|
09 | Barry Leiba | IESG state changed to Publication Requested from I-D Exists |
2023-08-23
|
09 | Barry Leiba | Document is now in IESG state Publication Requested |
2023-08-23
|
09 | Barry Leiba | ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did … ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? The document has broad agreement from the active working group. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? There are early implementations, though they are not listed. The document is expected to get wide adoption. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. There has been coordination with the SEDATE working group and its document draft-ietf-sedate-datetime-extended. This document is ready to proceed, but there is still a normative reference to the SEDATE document. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? N/A 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. As a product of the CBOR working group, the document has been reviewed by the CBOR experts. There is some simple ABNF in it, which does not need expert review. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? None identified. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The document is aimed at Proposed Standard, providing standards-track guidance on CBOR time tags and an anchor for IANA registrations. This is set in the datatracker after the working group decided to go for Standards Track (it was originally planned as Informational). 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes, and N/A. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) N/A 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? IEEE 1588-2008, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems" requires payment or subscription. It is used in other IETF documents. JCGM 100:2008, "Evaluation of measurement data — Guide to the expression of uncertainty in measurement" is a product of the Joint Committee for Guides in Metrology. It is freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. No. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? draft-ietf-sedate-datetime-extended is in the SEDATE working group's processing. It has completed working group last call and is in the hands of the IESG. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No. 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The IANA Considerations section is clear and complete. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. Two new registries are created, and each will need a designated expert. It is reasonable to ask the authors of this document to serve in that role. Explanations and instructions are clear. |
2023-08-23
|
09 | Barry Leiba | Intended Status changed to Proposed Standard from Informational |
2023-08-23
|
09 | Barry Leiba | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2023-07-23
|
09 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-09.txt |
2023-07-23
|
09 | Carsten Bormann | New version accepted (logged-in submitter: Carsten Bormann) |
2023-07-23
|
09 | Carsten Bormann | Uploaded new revision |
2023-07-09
|
08 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-08.txt |
2023-07-09
|
08 | Carsten Bormann | New version accepted (logged-in submitter: Carsten Bormann) |
2023-07-09
|
08 | Carsten Bormann | Uploaded new revision |
2023-06-28
|
07 | Christian Amsüss | Added to session: interim-2023-cbor-11 |
2023-06-28
|
07 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-07.txt |
2023-06-28
|
07 | Carsten Bormann | New version accepted (logged-in submitter: Carsten Bormann) |
2023-06-28
|
07 | Carsten Bormann | Uploaded new revision |
2023-06-28
|
06 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-06.txt |
2023-06-28
|
06 | Carsten Bormann | New version accepted (logged-in submitter: Carsten Bormann) |
2023-06-28
|
06 | Carsten Bormann | Uploaded new revision |
2023-06-14
|
05 | Christian Amsüss | Added to session: interim-2023-cbor-10 |
2023-03-26
|
05 | Christian Amsüss | Added to session: IETF-116: cbor Thu-0600 |
2023-03-13
|
05 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-05.txt |
2023-03-13
|
05 | Carsten Bormann | New version accepted (logged-in submitter: Carsten Bormann) |
2023-03-13
|
05 | Carsten Bormann | Uploaded new revision |
2023-01-25
|
04 | Christian Amsüss | Added to session: interim-2023-cbor-02 |
2023-01-11
|
04 | Barry Leiba | ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did … ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? The document has broad agreement from the active working group. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? There are early implementations, though they are not listed. The document is expected to get wide adoption. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. There has been coordination with the SEDATE working group and its document draft-ietf-sedate-datetime-extended. It would be good to explicitly note the last call on the SEDATE mailing list. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? N/A 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. As a product of the CBOR working group, the document has been reviewed by the CBOR experts. There is some simple ABNF in it, which does not need expert review. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? None identified. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? The document is aimed at Informational, providing guidance on CBOR time tags and an anchor for IANA registrations. This is set in the datatracker and the working group decided not to go for Standards Track on this. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes, and N/A. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) N/A 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? IEEE 1588-2008, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems" requires payment or subscription. It is used in other IETF documents. JCGM 100:2008, "Evaluation of measurement data — Guide to the expression of uncertainty in measurement" is a product of the Joint Committee for Guides in Metrology. It is freely available. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. No. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? draft-ietf-sedate-datetime-extended is in the SEDATE working group's processing. It has completed working group last call and is in the hands of the document shepherd. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No. 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The IANA Considerations section is clear and complete. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. Two new registries are created, and each will need a designated expert. It is reasonable to ask the authors of this document to serve in that role. Explanations and instructions are clear. |
2023-01-11
|
04 | Barry Leiba | Changed consensus to Yes from Unknown |
2023-01-11
|
04 | Barry Leiba | Intended Status changed to Informational from None |
2023-01-11
|
04 | Barry Leiba | IETF WG state changed to In WG Last Call from WG Document |
2023-01-11
|
04 | Barry Leiba | Notification list changed to barryleiba@computer.org because the document shepherd was set |
2023-01-11
|
04 | Barry Leiba | Document shepherd changed to Barry Leiba |
2023-01-11
|
04 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-04.txt |
2023-01-11
|
04 | Carsten Bormann | New version accepted (logged-in submitter: Carsten Bormann) |
2023-01-11
|
04 | Carsten Bormann | Uploaded new revision |
2023-01-11
|
03 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-03.txt |
2023-01-11
|
03 | Carsten Bormann | New version accepted (logged-in submitter: Carsten Bormann) |
2023-01-11
|
03 | Carsten Bormann | Uploaded new revision |
2022-10-24
|
02 | Barry Leiba | Added to session: IETF-115: cbor Thu-1700 |
2022-10-05
|
02 | Barry Leiba | Added to session: interim-2022-cbor-15 |
2022-10-04
|
02 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-02.txt |
2022-10-04
|
02 | Carsten Bormann | New version accepted (logged-in submitter: Carsten Bormann) |
2022-10-04
|
02 | Carsten Bormann | Uploaded new revision |
2022-07-28
|
01 | Christian Amsüss | Added to session: IETF-114: cbor Thu-1730 |
2022-07-27
|
01 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-01.txt |
2022-07-27
|
01 | Carsten Bormann | New version accepted (logged-in submitter: Carsten Bormann) |
2022-07-27
|
01 | Carsten Bormann | Uploaded new revision |
2022-04-20
|
00 | Christian Amsüss | Added to session: interim-2022-cbor-06 |
2021-11-20
|
00 | (System) | Document has expired |
2021-11-05
|
00 | Christian Amsüss | Added to session: IETF-112: cbor Thu-1430 |
2021-07-16
|
00 | Christian Amsüss | Added to session: IETF-111: cbor Fri-1430 |
2021-05-19
|
00 | Barry Leiba | Changed document external resources from: to: github_repo https://github.com/cbor-wg/time-tag |
2021-05-19
|
00 | Barry Leiba | This document now replaces draft-bormann-cbor-time-tag instead of None |
2021-05-19
|
00 | Carsten Bormann | New version available: draft-ietf-cbor-time-tag-00.txt |
2021-05-19
|
00 | (System) | WG -00 approved |
2021-05-19
|
00 | Carsten Bormann | Set submitter to "Carsten Bormann ", replaces to draft-bormann-cbor-time-tag and sent approval email to group chairs: cbor-chairs@ietf.org |
2021-05-19
|
00 | Carsten Bormann | Uploaded new revision |