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

[Paul Hoffman <[e-mail]>]

This message goes along with the -15 draft I just submitted. The diffs are at:
   https://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-in-json-15

--Paul Hoffman

On Apr 25, 2018, at 12:10 AM, Magnus Westerlund <[e-mail]> wrote:
> 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.

Got it. I added a Privacy Considerations section that includes that, with an example.

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

Done. 

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

No; instead, I (and every JSON-capable person reading the document) didn't realize that when the draft said "JSON integer" and "JSON boolean" for the past few years that it was just talking jibberish. I fixed this to be clear that they are all JSON numbers, and what the limitations of those numbers are.

Side note to everyone: ***this*** is exactly why having external-to-the-clique reviews of Internet Drafts is valuable in the IETF.


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

Yep, I agree.

On Apr 27, 2018, at 5:53 PM, Amanda Baber via RT <[e-mail]> wrote:

> I don't have any insight into whether this is required, but it should be noted that the media type template in the IANA Considerations section doesn't include the "Fragment identifier considerations" and "Deprecated alias names for this type" fields introduced in RFC 6838.

"Fragment identifier considerations" does seem required, but "Deprecated alias names for this type" is an optional subfield of "Notes".