On Apr 24, 2018, at 8:13 AM, Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx> 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
