[Cbor] Benjamin Kaduk's No Objection on draft-ietf-cbor-tags-oid-06: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-cbor-tags-oid-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cbor-tags-oid/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I made a PR at https://github.com/cbor-wg/cbor-oid/pull/9 with an
editorial suggestion (it ended up being just one -- well done!).

Is there anything useful to say about how bstrs tagged in this way will
be (mis?)interpreted by implementations that don't understand these tag
values?

Section 2

   Tag TBD110: tags a byte string as the [X.690] encoding of a relative
   object identifier (also "relative OID").  Since the encoding of each
   number is the same as for [RFC6256] Self-Delimiting Numeric Values
   (SDNVs), this tag can also be used for tagging a byte string that
   contains a sequence of zero or more SDNVs.

I did not think that CBOR was prone to reusing tag values for types that
are semantically different but happen to have the same binary encoding
rules.  Should generic SDNVs get a dedicated tag?

Section 7.1

Please note which range (and encoded length?) the allocations should
come from.  Alternately, mentioning specific requested values here might
be wise (given that there are examples that assume specific values).

Section 8

We might mention something about how when tag factoring is in use you
have to be careful that the only bstrs being affected do contain OIDs,
and inadvertently tagging a compound structure that sometimes contains
non-OID bstrs (in the relevant places) can have unexpected effects.

Section 9.1

AFAICT RFC 6256 only needs to be normative because of the way the
control operators are defined, and we rely on BER for everything else.
(Also, it looks like BER has more strict requirements than SDNV for the
minimal-length encoding, though I did not investigate this very
thoroughly.)