Reviewer: Magnus Westerlund
Review result: Ready with Issues
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?
