Hi Paul,
See inline.
Den 2018-04-24 kl. 17:50, skrev Paul Hoffman:
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.
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 +46 10 7148287
Torshamnsgatan 23 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx
----------------------------------------------------------------------
