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

[Magnus Westerlund <[e-mail]>]

Hi Paul,

See inline.


Den 2018-04-24 kl. 17:50, skrev Paul Hoffman:
> 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.

Exactly, it is the usage of this format that determines if it will be 
privacy sensitive or not. Thus, I think there is a need to note this 
possibility, and note that it is up to the profile / usage definition of 
this format to define what safe guards are needed. But, I think it is 
necessary to spend a paragraph to be explicit about the potential risk.

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

To my understanding is that all things this specification defines, 
including optional fields or features where one needs to read/understand 
the reference is a normative reference.

Please see IESG statements on normative references, especially note 1:
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/


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

This is not that clear. At least not to me. I have limited experience 
with JSON so I try to understand what is written rather than implicit.

    o  All members whose values that are always 16 bits or shorter are
       represented by JSON integers.  One-bit values are represented as
       JSON booleans.

There are no definition of JSON integers in RFC 8259 that I can find.
There is a single mention of integers in the Numbers section.

So maybe that needs to be defined so that it is clear.


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

My view is that if there is an underlying limitation to this field 
value, then it would make sense to make that explicit, even if the JSON 
representation has no such limitation. You had no issue doing that 
limitation when it the field is a 16-bit unsigned integer for example. 
Also, it is a question if this encoding of the DNS message accepts loss 
of precision in the field's value. And that I can't judge I don't 
understand the utilization of this field to comment on it.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------