Re: [Tsv-art] [Ext] Tsvart last call review of draft-hoffman-dns-in-json-14

[Paul Hoffman <[e-mail]>]

On Apr 24, 2018, at 8:13 AM, Magnus Westerlund <[e-mail]> wrote:
> 
> 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.

It is no more likely in this format than in any format that can be used for traffic logs. If there is a profile of this format that is to be used for traffic between an individual and a server, a privacy consideration in that profile could be warranted.

> 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?

Given that all fields for this format are optional, I had a hard time deciding whether things like this would be normative or informative. I can move those refs after the IESG review.

> 
> 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?

Yes.

> Searching the document,
> this appears to be the only defined value that uses numbers, is that correctly
> noted?

No. Almost everything in Section 2.1 (including the booleans!) are numbers.

> 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?

This is a matter for JSON (and thus RFC 8259), not for this format, I believe.

--Paul Hoffman