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

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 24 April 2018 15:13 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: tsv-art@ietf.org
Delivered-To: tsv-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2696912D943; Tue, 24 Apr 2018 08:13:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: tsv-art@ietf.org
Cc: draft-hoffman-dns-in-json.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.79.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152458281508.28916.6332509153215192043@ietfa.amsl.com>
Date: Tue, 24 Apr 2018 08:13:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/pJbTgwKsICRxVPQwON38HeW_mG0>
Subject: [Tsv-art] Tsvart last call review of draft-hoffman-dns-in-json-14
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Apr 2018 15:13:35 -0000

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.

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?