[Cbor] draft-ietf-cbor-time-tag completion (AUTH48) -- please check and reply

[Carsten Bormann <[e-mail]>]

As you may have noticed, the time-tag specification [1] is currently in AUTH48 processing, i.e., the RFC-editor is working with authors, chairs, and the responsible AD to complete the editing of the RFC.

[1]: https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-12.html

In parallel to other editing work (see the thread at [2] for all the excruciating details), we need to resolve one issue that was brought up by Rohan Mahy in his post-approval review (thread started at [3]):

[2]: https://mailarchive.ietf.org/arch/browse/auth48archive/?gbt=1&index=ur78QaT8pS9hN8ma5iY8HR5yVZI

[3]: https://mailarchive.ietf.org/arch/msg/cbor/7BQ5cxMw7HRztxEONbPkXbN2WL0

key -1 is used for timescale in 3.4 and the ABNF, but is not listed in the initial IANA registration in Table 4.
This needs to be repaired.
We could also use the opportunity of this repair to address Rohan's additional comment on the potential need for a critical value for this key.
This unfortunately cannot simply be the positive counterpart to -1 as in other elective/critical pairs, namely 1, as that is already taken for base time.
We also could address more of Rohan’s post-approval comments, see [4] for my response to that at the time (which also calls for work on a wiki [5] that can proceed independently).

[4]: https://mailarchive.ietf.org/arch/msg/cbor/ZXEvM4bwZGsbQkjqzu1aIjos5vU
[5]: https://github.com/cbor-wg/time-tag/wiki

My proposal is to do these steps:

* (1) We strengthen the pairing of unsigned and negative keys, probably by asking the designated expert to check whether both critical and elective variants should be provided (goes into IANA considerations).
* (2) We pair -1 (elective) with 13 (critical) for timescale and add IANA considerations for both.
* (3) We change the elective timescale to -13 and keep -1 as an alias for backwards compatibility, and add IANA considerations for that as well.

I’m pretty sure we should do (1) and (2), and probably also (3).

Since the RFC editor works on an XML form of the document, I'll not point to a PR but provide my proposal for the desired changes in the classic OLD:/NEW: format.

(1)
OLD: in para 7.3-3:
   Note that negative
   integers indicate an elective key, while unsigned integers indicate a
   key that either provides a base time or is critical.
NEW:
   Note that negative
   integers indicate an elective key, while unsigned integers indicate a
   key that either provides a base time or is critical.
   The designated expert is requested to discuss with the registrant
   whether it is desirable to register a pair of an elective and a
   critical key for the same information, where the elective key value
   is the negative of the critical key (similar to how for example -11
   and 11 have been assigned in Table 4).


(2)
OLD:
3.4.  Key -1: Timescale
NEW:
3.4.  Keys -1 and 13: Timescale

OLD:
   Key -1 is used to indicate a timescale.
NEW:
   Keys -1 and 13 are used to indicate a timescale, where key 13 is critical.
   Each extended time data item MUST NOT
   contain more than one of these keys.

OLD:
   $$ETIME-ELECTIVE //= (-1 => $ETIME-TIMESCALE)
NEW:
   $$ETIME-ELECTIVE //= (-1 => $ETIME-TIMESCALE)
   $$ETIME-CRITICAL //= (13 => $ETIME-TIMESCALE)

(Same addition also in Appendix A.)

OLD:
   If key -1 is not present, the default timescale value 0 is implied.
NEW:
   If neither of the keys is present, the default timescale value 0 is implied.


OLD: (Table 4)
NEW: add these rows:
| -1  | timescale (elective)        | [RFC9581] |
| 13  | timescale (critical)        | [RFC9581] |


(3) after doing (2)
OLD:
3.4.  Keys -1 and 13: Timescale
NEW:
3.4.  Keys -1, -13, and 13: Timescale

OLD:
   Keys -1 and 13 are used to indicate a timescale, where key 13 is critical.
NEW:
   Keys -1, -13 and 13 are used to indicate a timescale, where key 13 is critical.
   Keys -1 and -13 have identical semantics (they are both assigned as
   key -1 was chosen first and then when key 13 was added it appeared desirable to have a
   negative equivalent).

OLD:
   $$ETIME-ELECTIVE //= (-1 => $ETIME-TIMESCALE)
NEW:
   $$ETIME-ELECTIVE //= (-1 => $ETIME-TIMESCALE)
   $$ETIME-ELECTIVE //= (-13 => $ETIME-TIMESCALE)

(Same addition also in Appendix A.)

OLD: (Table 4)
| -1  | timescale (elective)        | [RFC9581] |
NEW:
| -1  | timescale (elective) legacy | [RFC9581] |
| -13 | timescale (elective)        | [RFC9581] |


Please do check these text proposals and indicate here whether you are OK with them.

Is there appetite in the WG for addressing some of Rohan’s other comments?
I would like to do a mostly minimal change here, hence just the items above, but that is of course for the WG to decide.
(I hope we can push the above through without the AD pushing the document back into a WG state.
That is of course for the AD to decide!)

Grüße, Carsten