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

[Qin Wu <[e-mail]>]

Carsten:
Thank for your quick feedback and proposed changes, we are good now.

-----邮件原件-----
发件人: Carsten Bormann [mailto:[e-mail]] 
发送时间: 2023年10月19日 19:31
收件人: Qin Wu <[e-mail]>
抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail]
主题: Re: [Last-Call] [Iot-directorate] Iotdir telechat review of draft-ietf-cbor-time-tag-10

Hi Qin,

below are some more reactions to comments where I think you still see a need for action.  (I have removed the other comments to keep this message relatively short.)

All changes discussed below have been added to

https://github.com/cbor-wg/time-tag/pull/21

Thank you!

Grüße, Carsten


> On 2023-10-19, at 04:10, Qin Wu <bill.wu=[e-mail]> wrote:
> 
> 
> 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.

Clearly, the extended time receives most of the attention, as the duration and period can then just build on this.
We wouldn’t call extended time overspecified — it just happens that the representation of time stamps has a lot of specifics that are based on the art of keeping time and frequency and the way we map this into civil time.
So we don’t see a need for change here.

[Qin Wu-1] OKAY
>> 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.

Indeed.  I have added a reference to RFC 8949 and used “defined” twice:
https://github.com/cbor-wg/time-tag/pull/21/commits/7f4df26

[Qin Wu-1] Thanks, looks good.
>> 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.

Right.

>> 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.

I clarified the (unfortunate) contraction “future times” in:
https://github.com/cbor-wg/time-tag/pull/21/commits/9fd7b67

I think the part about the intents really needs to be read in conjunction with the next paragraph, which identifies the extension point.

[Qin Wu-1] Good, agree with what you said.
>> 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.

Now in
https://github.com/cbor-wg/time-tag/pull/21/commits/a2f7f67

I also clarified the example in 3.7:

https://github.com/cbor-wg/time-tag/pull/21/commits/86c26b9

[Qin Wu-1] Good, thanks.
>> 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.

This is not exactly a duplication, as Section 3 discusses positioning information, which is not discussed in Section 2.  Note that these are just examples, and I added some text indicating that the text in Section 3 is an example.

Now in
https://github.com/cbor-wg/time-tag/pull/21/commits/559b581

[Qin Wu-1] Good, thanks.
>> 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.

We generally try not to restate too much terminology out of normatively referenced specifications; the reader really needs to read RFC 8610 to fully understand the CDDL snippets.

[Qin Wu-1] Works for me.
>> 12.	Section 3.5.4 said:
>> "For this document, uncertainty is defined as in Section 2.2.3 of [GUM]:

[…]
> I am wondering why we choose to use coverage factor 2 instead of 3. Is there any rationale behind?

k=2 simply appears to be the more commercially relevant one in metrology.
We could easily define another map key (say, -17) for a coverage factor of 3, or one that includes the coverage factor with the uncertainty.
Do you have evidence that we should do this now?
(This is a registry, so it easily can be added later.)

[Qin Wu-1] No evidence, thank for your clarification. I agree with your strategy.
> 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?  

Indeed, this was already noted by Thomas Fossati in his artart review and corrected in https://github.com/cbor-wg/time-tag/pull/20/commits/ba9ce0c

[Qin Wu-1] Good.
>> 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.

Now in
https://github.com/cbor-wg/time-tag/pull/21/commits/b6a7927

[Qin Wu-1] Thanks