Skip to main content

Concise Binary Object Representation (CBOR) Tags for Object Identifiers
draft-ietf-cbor-tags-oid-08

Yes

Erik Kline
Francesca Palombini

No Objection

Roman Danyliw
(Alvaro Retana)
(Martin Duke)
(Martin Vigoureux)

Note: This ballot was opened for revision 06 and is now closed.

Erik Kline
Yes
Francesca Palombini
Yes
John Scudder
No Objection
Comment (2021-04-07 for -06) Sent
1. Section 2:

   Since the semantics of absolute and relative object identifiers
   differ, this specification defines two tags, collectively called the
   "OID tags" here:

Sure looks like three tags to me.

2. Section 5:

Since this is the first place you refer to CDDL, put your reference to RFC 8610 here instead of §6?
Murray Kucherawy
No Objection
Comment (2021-04-07 for -06) Sent
For Zaheduzzaman: The downref was properly identified during the Last Call.
Roman Danyliw
No Objection
Zaheduzzaman Sarker
No Objection
Comment (2021-04-06 for -06) Not sent
IDnits returned a downref error.
Éric Vyncke
No Objection
Comment (2021-04-07 for -06) Sent
Thank you for the work put in this document.

Thank you also for your reply to Ines Robles' review for the IoT directorate:
https://datatracker.ietf.org/doc/review-ietf-cbor-tags-oid-06-iotdir-telechat-robles-2021-04-06/

Regards

-éric
Alvaro Retana Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Benjamin Kaduk Former IESG member
No Objection
No Objection (2021-04-07 for -06) Sent
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.)
Lars Eggert Former IESG member
No Objection
No Objection (2021-04-06 for -06) Sent
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 2, paragraph 2, nit:
-    i.e. a (sub)sequence of such integer values.)
+    i.e., a (sub)sequence of such integer values.)
+        +

Section 2.1, paragraph 14, nit:
-    regexp is invalid.
+    regular expression is invalid.
+       +++++   +++++++

The following URLs in the document failed to return content:
 * http://www.penango.com/
Martin Duke Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Robert Wilton Former IESG member
(was Discuss) No Objection
No Objection (2021-05-19 for -07) Sent
Clearing discuss based on -07 version of the document.

----

I found this document to be interesting because I knew from the title that it was going to only be 4 pages long and say that OIDs are obviously encoded as a tagged array, hence I was surprised to see that was not the solution and it uses BER encoded OIDs instead.

The document explains, and I think that I understand why this has been done, but I question whether the title of the document and name of the tags is right.  Is it really a CBOR representation of OIDs, or is it actually a CBOR representation of BER encoded OIDs?  I.e., it is plausible that there would ever be a requirement for non BER encoded OIDs.  E.g., I'm not an ASN.1 expert, but say if somewhat wanted to do a CBOR encoding of ASN.1, then it is not obvious to me that they would use a BER encoding for OIDs.  Hence the suggestion is to make the title, abstract, and name of the tags clear that it is about the CBOR encoding or BER encoded OIDs.

In the introduction:
   Since the semantics of absolute and relative object identifiers
   differ, this specification defines two tags, collectively called the
   "OID tags" here:

I presume that this should be three tags?


In section 4.1.  Tag Factoring Example: X.500 Distinguished Name:

The diagram uses a mix of single letters (e.g. c for country), and a full name "street".  Is this how the X.500 attributes are defined?  Otherwise it might be clearer to always use their full names.

    The country and street RDNs are single-valued. The second and fourth RDNs are multi-valued.

Perhaps:  "The country (first) and street (third) RDNs are single-valued. The second and fourth RDNs are multi-valued."

    h'550407': "Los Angeles", h'550408': "CA",

I think that the example would be more clear by splitting the city and county onto separate lines.

Finally, the document contains these two sentences that seem to somewhat conflict with each other:

"While these sequences can easily be represented in CBOR arrays of unsigned integers, a more compact representation can often be achieved by adopting the widely used representation of object identifiers defined in BER; this representation may also be more amenable to processing by other software that makes use of object identifiers."

compared to:

"Staying close to the way object identifiers are encoded in ASN.1 BER makes back-and-forth translation easy; otherwise we would choose a more efficient encoding."

Regards,
Rob