Skip to main content

Last Call Review of draft-hoffman-dns-in-json-14
review-hoffman-dns-in-json-14-tsvart-lc-westerlund-2018-04-24-00

Request Review of draft-hoffman-dns-in-json
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2018-04-20
Requested 2018-03-23
Authors Paul E. Hoffman
I-D last updated 2018-04-24
Completed reviews Opsdir Last Call review of -14 by Shwetha Bhandari (diff)
Secdir Last Call review of -14 by Watson Ladd (diff)
Genart Last Call review of -13 by Stewart Bryant (diff)
Tsvart Last Call review of -14 by Magnus Westerlund (diff)
Genart Telechat review of -15 by Stewart Bryant (diff)
Assignment Reviewer Magnus Westerlund
State Completed
Request Last Call review on draft-hoffman-dns-in-json by Transport Area Review Team Assigned
Reviewed revision 14 (document currently at 16)
Result Ready w/issues
Completed 2018-04-24
review-hoffman-dns-in-json-14-tsvart-lc-westerlund-2018-04-24-00
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?