Hi, Carsten: -----邮件原件----- 发件人: Carsten Bormann [mailto:cabo@xxxxxxx] 发送时间: 2023年10月18日 21:04 收件人: Qin Wu <bill.wu@xxxxxxxxxx> 抄送: iot-directorate@xxxxxxxx; cbor@xxxxxxxx; draft-ietf-cbor-time-tag.all@xxxxxxxx; last-call@xxxxxxxx 主题: Re: [Last-Call] [Iot-directorate] Iotdir telechat review of draft-ietf-cbor-time-tag-10 Hi Qin, thank you for this detailed review. Please see my responses inline below. Note that I will cite from the slightly updated draft that already incorporates the reactions to Thomas Fossati’s review: https://github.com/cbor-wg/time-tag (Please use the link “Compare Editor's Copy to Working Group Draft” on this page to see the difference.) The proposed changes resulting from your review are in: https://github.com/cbor-wg/time-tag/pull/21 (see specific links below). > 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. The document defines a lot of different pieces of information that can be added to a time stamp. Usage in a constrained environment is unlikely to use a large number of them at the same time. One example for a constrained use would be a timestamp from a sensor that resolves time to microseconds: 1001(1: 1697619696, -6: 873294} (This would be equivalent to 0:("2023-10-18T09:01:36.873294Z"), but does require neither decimal nor floating point arithmetic to be implemented on the constrained node.) [Qin Wu] Good, thank for clarification. > 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? The abstract is saying: >> 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. So it puts the tag for time in the floodlight, but also mentions there are two other new tags. Adding this to a total of three is left as an exercise for the reader. Would the abstract benefit from explicitly saying this? [Qin Wu] Good analogy, I am also under impression that the tag for the time is well over-specified while the other two not. I l would like to leave this to authors to decide. > 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? (That sentence is a copy from the abstract.) [Qin Wu] OK. > 3. Section 1.1 mentions including C++14's 0bnnn binary literals, Can you provide a reference for this? This sentence is a remnant from a copy/paste that is no longer needed. Thomas found it, too; so we already have removed it from the Editor’s copy. (The reference is: Section 2.14.2 Integer literals [lex.icon] in the C++14 standard (ISO/IEC 14882:2014).) [Qin Wu] Okay, make sense to me. > 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? Tag 0 and 1 are defined with UTC, so, yes, only the new CBOR tags allow you to specify TAI. [Qin Wu] Good, it would be great to make this clear in the text. > 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? This sentence is specifically about IXDTF (defined in draft-ietf-sedate-datetime-extended), and the Sections 3.6 and 3.7 define map keys to include IXDTF information in the new CBOR time tags. [Qin Wu] OK, so all information can be carried using extended time format in this document. > Or leave this for future extension, e.g., extension defined in section 3.7? I’m not sure why you label this a “future” extension — it is right there in this document. [Qin Wu] I think the root cause of my confusion comes from "Intents might include...", I thought this is some new introduced intents, And " in particular for future times ", confusion might also come, is this future extension to express some new times in the future. Hope this clarifies why I got confusion. > Why leave this for future extension? Write another document for these future extensions? (See above.) [Qin Wu] See above as well. > 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。 The time-tag document simply does not change anything about tag 1. It defines new tags, among which 1001. It is not clear what being backward compatible with tag 1 would mean for 1001 — it is a different tag. [Qin Wu] Agree, this is a different tag, so it is not backward compatible issues. The new tags can support decimal and big float representation while existing tag 1 can not support decimal or bigfloat representations. In other words, The new tags can represent all time format supported by tag 1, in addition, the new tag can represent some other time format which can not be supported by tag1. The new tags > 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？ The existing tags 0 and 1 are fine for applications where their capabilities suffice. There is no intention to replace them, just to supplement them with tag 1001 (and also provide tag 1002 and 1003 with new capabilities). [Qin Wu] Okay, if my understanding is correct, tag 0 and 1 are designed for resource constraint environment, it is worth keep them. > 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? “critical” and “elective” are terms that are well defined in other protocols; we could indeed be more explicit about defining them here. Now https://github.com/cbor-wg/time-tag/pull/21/commits/85f885f [Qin Wu] Thanks for taking it into account. > 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? When a new key is registered, it is the task of the registrant to decide whether the key needs to be “critical” or “elective”. Generally, if the extended time can still be meaningfully used without understanding (and thus implementing) the new key, is should be marked “elective” (and get a negative number); if the extended time is not useful without that information, choose “critical”. This is similar to the critical-flag in draft-ietf-sedate-datetime-extended. [Qin Wu] Good clarification, maybe add some clarification text in the update. > 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. I believe this repetition is harmless; often registry information is read separately from the other information in the document. [Qin Wu] Works for me. Just point out this duplication. > 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? nint is defined in the CDDL prelude (see Section 2, 3.3, and Appendix D of RFC 8610). It means “negative integer” (just like uint means “unsigned integer”). [Qin Wu] Good to know about this, thank for clarification, maybe some reference or some notes/marks should be added somewhere. > 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? Yes. > I also feel "value 0 is implied" is not formal language. I read this as a formal statement. (I may be biased by the use of #implied in DTDs for implicit defaults.) Changed this to: If key -1 is not present, the default timescale value 0 is implied. Now in https://github.com/cbor-wg/time-tag/pull/21/commits/48fce64 [Qin Wu] Good, thanks. > 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. Unfortunately, you’ll need to read [GUM] to make good use of the information here. Restating the definitions from this rather formal and specific, but very well-accepted document would be fraught with danger. [Qin Wu] I understand measurand now by reading B2.9 of [GUM]. K in "K=2" represent coverage factor See section 6.2 and section 6.3 of [GUM]: " 6.2 Expanded uncertainty 6.2.1 The additional measure of uncertainty that meets the requirement of providing an interval of the kind indicated in 6.1.2 is termed expanded uncertainty and is denoted by U. The expanded uncertainty U is obtained by multiplying the combined standard uncertainty uc(y) by a coverage factor k: .... " " 6.3 Choosing a coverage factor 6.3.1 The value of the coverage factor k is chosen on the basis of the level of confidence required of the interval y − U to y + U. In general, k will be in the range 2 to 3. However, for special applications k may be outside this range. Extensive experience with and full knowledge of the uses to which a measurement result will be put can facilitate the selection of a proper value of k. " I am wondering why we choose to use coverage factor 2 instead of 3. Is there any rationale behind? Secondly, I think "Extended Uncertainty" is the term used in this document, in [GUM], I believe the term "Expanded uncertainty" Is used, should these two terms be used consistently? > Can you provide a usage example for key = -7? 1001(1: 1697619696, -6: 873294, -7: 0.001} or 1001(1: 1697619696, -6: 873294, -7: {1: 0, -6: 1000}} …would indicate a time that is expressed to a resolution of a microsecond, but with an uncertainty of a millisecond. [Qin Wu] Good to add this example in section 3.5.4. > 13. Section 3.6 > Please clarify with an example on what key semantics difference > between key 10 and key -10 10 is equivalent to setting the critical-flag in draft-ietf-sedate-datetime-extended, -10 means the information is elective. [Qin Wu] Okay. > 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? Actually, the text says: Keys -10 and 10 MUST NOT both be present. and When keys -11 and 11 both are present, the two maps MUST NOT have entries with the same map keys. The reason these differ is that there can only be one Time Zone Hint, and that is either elective or critical; two values just do not make sense. For the IXDTF Suffix Information, there may be multiple keys in that information (“u-ca” in the example given), and they may differ in their IXDTF “critical” flag. [Qin Wu] Thank for clarification, it makes sense to me now. > 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? If you want to say “10 seconds after Neil Armstrong set a foot on the moon”, you would use “the time when Neil Armstrong set a foot on the moon” as the epoch identified by the context (not specified here how to do that), and use a duration of 1002({1: 10}). [Qin Wu] Good, thank for clarification. > 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)." #6 is CDDL notation for a tag (which happens to have CBOR major type 6). The content of this tag is a map (indicated in CDDL by using braces as in {}), which has CBOR major type 5. [Qin Wu] I see now, thanks. Grüße, Carsten > > -----邮件原件----- > 发件人: Iot-directorate [mailto:iot-directorate-bounces@xxxxxxxx] 代表 Qin > Wu via Datatracker > 发送时间: 2023年10月18日 9:41 > 收件人: iot-directorate@xxxxxxxx > 抄送: cbor@xxxxxxxx; draft-ietf-cbor-time-tag.all@xxxxxxxx; > last-call@xxxxxxxx > 主题: [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 > Iot-directorate@xxxxxxxx > https://www.ietf.org/mailman/listinfo/iot-directorate > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
