Re: [Iot-directorate] Iotdir telechat review of draft-ietf-cbor-time-tag-10

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you, Qin, for your short-notice review.

As you may have seen, I have referred to your review in my “no objection” ballot.

Regards

-éric

From: Iot-directorate <[e-mail]> on behalf of Qin Wu <bill.wu=[e-mail]>
Date: Wednesday, 18 October 2023 at 03:43
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Iot-directorate] Iotdir telechat review of draft-ietf-cbor-time-tag-10
Resend the review to fix format issue.

Reviewer: Qin Wu
Review result: Ready with Nits
This document is well written and defines CBOR tags for time duration and period respectively.
I feel these CBOR tags introduces rich semantics to represent extended time format, which seems not suitable for resource constraint IoT environment, please correct me if I am wrong.
Here are a few comments on the v-10:
1.      Abstract
One CBOR tag or three CBOR tags?
It looks this document defines and register 3 CBOR tags, why in this abstract say only one CBOR tag is defined, together two CBOR tags? Does this means the other 3 CBOR tags are CBOR tags documented in some other specifications?
2.      Introduction
The Same comment of the abstract is applied to the introduction,
Why not say 3 CBOR tags are defined in this present document?
3.      Section 1.1 mentions including C++14's 0bnnn binary literals, Can you provide a reference for this?
4.      Section 2 said:
" Indication of timescale. Tags 0 and 1 are for UTC; however, some interchanges are better performed on TAI.
"
Can tag 0 and tag 1 be applied to TAI? For TAI, or only new CBOR tag should be applied to TAI?
5.      Section 2 also said:
" Intents might include information about time zones, daylight savings times, preferred calendar representations, etc. "
Has this additional information such as time zones already been supported by 3 CBOR tags defined by this document?
Or leave this for future extension, e.g., extension defined in section 3.7?
Why leave this for future extension? Write another document for these future extensions?
6.      Section 2 said:
"
The present specification does not take a position on whether tag 1 can be "fixed" to include, e.g., Decimal or BigFloat representations.  It does define how to use these representations with the extended time format. "
Confused, does this mean that time format defined in RFC8949 is not backward compatible with extended data format defined in this document since tag 1 can not be fixed to support decimalfraction and bigfloat while in this document key 4 and key 5 in extended data format can be used to support decimalfraction and bigfloat。
7.      Section 3
I am under impression that the extended time format defined in this document choose to define different CBOR tag, rather than extend from existing time related tags defined in RFC8949, which seems to me , backward compatible to the time related tags defined in RFC8949,
I am wondering whether the extended time format defined in this document is intended to replace time format defined in RFC 8949？
8.      Section 3 said:
" Supplementary information may also be provided by additional unsigned integer keys that are explicitly defined to provide supplementary information ("critical"; as these are required to be understood, there can be no confusion with Base Time keys).
Negative integer and text string keys always supply supplementary information ("elective", and this will not be explicitly stated below)."
What is the difference between critical and elective?
Not clear when I have to choose to use critical, when I have to choose to use elective?
In my impression critical is related to unsigned integer while elective is related to negative integer, so is there any use cases while only critical is allowed while elective is forbidden?
9.      Section 3 said:
" Additional keys can be defined by registering them in the Map Key Registry (Section 7.3).  Future keys may add:
   *  intent information such as timezone and daylight savings time,
      and/or possibly positioning coordinates, to express information
      that would indicate a local time."
I feel this paragraph is duplicated, which has already be described in section 2, paragraph 2.
10.     In the formal definition of Tag 1001 in CDDL in section 3, nint/text is used, what does nint in "nint/text" mean? uint or unsigned integer?
11.     Section 3.4 said:
"If key -1 is not present, timescale value 0 is implied."
Does this mean timescale value 0 is default value?
I also feel "value 0 is implied" is not formal language.
12.     Section 3.5.4 said:
"For this document, uncertainty is defined as in Section 2.2.3 of [GUM]: "parameter, associated with the result of a measurement, that characterizes the dispersion of the values that could reasonably be attributed to the measurand".  More specifically, the value for this key represents the extended uncertainty for k = 2, in seconds. "
What does measurand in this paragraph mean?
Is K in “K=2” Key 2? Can you provide reference for k=2? It is hard to understand without context information.
Can you provide a usage example for key = -7?
13.     Section 3.6
Please clarify with an example on what key semantics difference between key 10 and key -10
14.     Section 3.7
Section 3.6 and section 3.7 specify the rules for key 10,-10, key 11,-11.
Why allow key -10 and key 10 both present while not allow key -11 and key 11 both present? Present in the same map or in two different map?
15.     Section 4
"In combination with an epoch identified in the context, a duration can also be used to express an absolute time. "
Can you provide an example to use Duration as an absolute time?
16.     Section 5
Is #6 representing CBOR major type 6?
If yes, it seems not consistent with the text in section 3 " An extended time is indicated by CBOR tag 1001, the content of which is a map data item (CBOR major type 5)."

-----邮件原件-----
发件人: Iot-directorate [mailto:[e-mail]] 代表 Qin Wu via Datatracker
发送时间: 2023年10月18日 9:41
收件人: [e-mail]
抄送: [e-mail]; [e-mail]; [e-mail]
主题: [Iot-directorate] Iotdir telechat review of draft-ietf-cbor-time-tag-10

Reviewer: Qin Wu
Review result: Ready with Nits

This document is well written and defines CBOR tags for time duration and period respectively. I feel these CBOR tags introduces rich semantics to represent extended time format, which seems not suitable for resource constraint IoT environment, please correct me if I am wrong. Here are a few comments on the v-10: 1.Abstract One CBOR tag or three CBOR tags? It looks this document defines and register 3 CBOR tags, why in this abstract say only one CBOR tag is defined, together two CBOR tags? Does this mean that the other 2 CBOR tags are CBOR tags documented in some other specifications? 2.Introduction The Same comment of the abstract is applied to the introduction, Why not say 3 CBOR tags are defined in this present document? 3.Section 1.1 mentions including C++14's 0bnnn binary literals, Can you provide a reference for this?
4.Section 2 said: " Indication of timescale. Tags 0 and 1 are for UTC; however, some interchanges are better performed on TAI. " Can tag 0 and tag 1 be applied to TAI? For TAI, or only new CBOR tag should be applied to TAI? 5.Section 2 also said: " Intents might include information about time zones, daylight savings times, preferred calendar representations, etc. " Has this additional information such as time zones already been supported by 3 CBOR tags defined by this document? Or leave this for future extension, e.g., extension defined in section 3.7? Why leave this for future extension? Write another document for these future extensions? 6.Section 2 said: " The present specification does not take a position on whether tag 1 can be "fixed" to include, e.g., Decimal or BigFloat representations.  It does define how to use these representations with the extended time format. " Confused, does this mean that time format defined in RFC8949 is not backward compatible with extended data format defined in this document since tag 1 can not be fixed to support decimalfraction and bigfloat while in this document key 4 and key 5 in extended data format can be used to support decimalfraction and bigfloat。 7.Section 3 I am under impression that the extended time format defined in this document choose to define different CBOR tag, rather than extend from existing time related tags defined in RFC8949, which seems to me , backward compatible to the time related tags defined in RFC8949, I am wondering whether the extended time format defined in this document is intended to replace time format defined in RFC 8949？ 8.Section
3 said: " Supplementary information may also be provided by additional unsigned integer keys that are explicitly defined to provide supplementary information ("critical"; as these are required to be understood, there can be no confusion with Base Time keys). Negative integer and text string keys always supply supplementary information ("elective", and this will not be explicitly stated below)." What is the difference between critical and elective? Not clear when I have to choose to use critical, when I have to choose to use elective? In my impression critical is related to unsigned integer while elective is related to negative integer, so is there any use cases while only critical is allowed while elective is forbidden? 9.Section 3 said: " Additional keys can be defined by registering them in the Map Key Registry (Section 7.3).  Future keys may add:
   *  intent information such as timezone and daylight savings time,
      and/or possibly positioning coordinates, to express information
      that would indicate a local time."
I feel this paragraph is duplicated, which has already be described in section 2, paragraph 2. 10.In the formal definition of Tag 1001 in CDDL in section 3, nint/text is used, what does nint in "nint/text" mean? uint or unsigned integer? 11.Section 3.4 said: "If key -1 is not present, timescale value 0 is implied." Does this mean timescale value 0 is default value? I also feel "value
0 is implied" is not formal language. 12.Section 3.5.4 said: "For this document, uncertainty is defined as in Section 2.2.3 of [GUM]: "parameter, associated with the result of a measurement, that characterizes the dispersion of the values that could reasonably be attributed to the measurand".  More specifically, the value for this key represents the extended uncertainty for k = 2, in seconds. " What does measurand in this paragraph mean? Is K in “K=2”
Key 2? Can you provide reference for k=2? It is hard to understand without context information. Can you provide a usage example for key = -7? 13.Section
3.6 Please clarify with an example on what key semantics difference between key
10 and key -10 14.Section 3.7 Section 3.6 and section 3.7 specify the rules for key 10,-10, key 11,-11. Why allow key -10 and key 10 both present while not allow key -11 and key 11 both present? Present in the same map or in two different map? 15.Section 4 "In combination with an epoch identified in the context, a duration can also be used to express an absolute time. " Can you provide an example to use Duration as an absolute time? 16.Section 5 Is #6 representing CBOR major type 6? If yes, it seems not consistent with the text in section 3 " An extended time is indicated by CBOR tag 1001, the content of which is a map data item (CBOR major type 5)."



--
Iot-directorate mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/iot-directorate
--
Iot-directorate mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/iot-directorate