I've reviewed this document as part of TSV-ART's ongoing effort to
review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors
for their information and to allow them to address any issues raised.
Please always CC tsv-art at ietf.org if you reply to or forward this
review.

Sorry for the late review. Looking at the document I did not find any "transport" issues but another issue and some nits that I like to raise. 

Issue:

Security Consideration

I am missing a reference or discussion to that the contained values in this format likely contain privacy sensitive information if it can be linked to who the requester is. 

Nits:

Section 2.5:

   o  dateString - The date that the message was sent or received, given
      as a string in the standard format described in [RFC3339], as
      refined by Section 3.3 of [RFC4287]

Why isn't RFC3339 and RFC4287 includes as normative references for this specification. The above quote indicates that it would be required to look at these RFCs to implement handling of this value?


Section 2.5:  I wondered over this definition:

   o  dateSeconds - The date that the message was sent or received,
      given as the number of seconds since 1970-01-01T00:00Z in UTC
      time; this number can be fractional

It is not clear from how it is written, but I assume the format for this is a JSON number, i.e. as defined in Section 6 of rfc8259? Searching the document, this appears to be the only defined value that uses numbers, is that correctly noted? Considering that fractional seconds, and the potential for overflow. Any notes in the context of DNS representation about how small fractional values that can be represented?