Subject: [DNSOP] Passive DNS - Common Output Format (draft-dulaunoy-kaplan-passive-dns-cof-01)

From: Paul Vixie <[email-masked]>
Date: Wed, 15 Jan 2014 11:25:31 -0800

speaking for the authors of the draft below, i request adoption by
dnsop. --vixie

https://datatracker.ietf.org/doc/draft-dulaunoy-kaplan-passive-dns-cof/

Internet Engineering Task Force                              A. Dulaunoy
Internet-Draft                                                     CIRCL
Intended status: Informational                                 A. Kaplan
Expires: July 11, 2014                                           CERT.at
                                                                P. Vixie
                                                                H. Stern
                                                 Farsight Security, Inc.
                                                         January 7, 2014

                   Passive DNS - Common Output Format
                draft-dulaunoy-kaplan-passive-dns-cof-01

Abstract

   This document describes a common output format of Passive DNS Servers
   which clients can query.  The output format description includes also
   in addition a common semantic for each Passive DNS system.  By having
   multiple Passive DNS Systems adhere to the same output format for
   queries, users of multiple Passive DNS servers will be able to
   combine result sets easily.

...

---

From: Tony Finch <[email-masked]>
Date: Thu, 16 Jan 2014 14:27:42 +0000

> https://datatracker.ietf.org/doc/draft-dulaunoy-kaplan-passive-dns-cof/

A few questions / comments:

The ws non-terminal isn't defined. I guess it is supposed to be

	ws = *( %x10 / %x09 )

i.e. no newlines within a JSON object, which is different from the
definition of ws in RFC 4627. (Maybe use core ABNF WSP instead?)

The ABNF specifies that the field names are not quoted (the quotes are
part of the ABNF metasyntax not part of the language it specifies) which
is incompatible with JSON and disagrees with the examples in the appendix.

The appendix could do with some rubric to explain the backslashes.

Are numeric rrtypes represented as JSON numbers? Or a "TYPEnnn" string?

I guess time stamps are represented as JSON numbers.

How are sensor_id octet strings encoded as JSON strings?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Andreas Gustafsson <[email-masked]>
Date: Thu, 16 Jan 2014 19:54:36 +0200

> https://datatracker.ietf.org/doc/draft-dulaunoy-kaplan-passive-dns-cof/

I also have some comments on the draft.

Section 3.3, "Mandatory Fields", states:

   rdata MAY be an array as defined in JSON [RFC4627]

If the purpose of such an array is to represent an RRset containing
multiple RRs, the draft should say so.  It should also be clear
whether an implementation MAY represent all RRsets as arrays for
consistency, or MUST treat single-RR RRsets as a special case
and represent them as strings.

Section 3.3.2, "rrtype", states:

    The resource record type can be any values as described by IANA in
    the DNS parameters document in the section 'DNS Label types'

Presumably 'DNS Label types' should read 'Resource Record (RR) TYPEs'.

Section 3.3.3, "rdata", states:

    In general, this is to be interpreted as string.

It's not clear to me what "interpreted as a string" means.  The value
either is a JSON string or it is not; is this saying that non-string
values such as JSON integers, booleans, and objects should somehow be
converted into strings?  And if this is done only "in general", what
are the exceptions?  Or is this just a strange way of saying "This is
either a string or an array of strings"?

    A client MUST be able to interpret any value which is legal as the
    right hand side in a DNS zone file RFC 1035 [RFC1035] and RFC 1034
    [RFC1034].

A reader who follows the reference to RFC1034/RFC1035 and searches for
"zone file" will find nothing, as the term used in those documents is
"master file".

The master file format has the concept of a "current origin" which
affects the interpretation of unqualified domain names and the special
@ token.  I assume the intent is to interpret the value as if a
current origin of "." is in effect; the draft should say so explicitly.

It would also be good to state whether or not the value may
contain grouping parentheses, embedded newlines, and comments.

It would be helpful if Appendix A contained an example of an RRset
containing more than one RR.

To illustrate the interplay between the master file and JSON quoting
mechanisms, it would also be helpful if Appendix A could contain
examples illustrating the encoding of RRs like the following:

    example.com.   RP  john\.smith.example.com. .
    a.example.com. TXT "one string"
    b.example.com. TXT "two" "strings"
    c.example.com. TXT "string with \"embedded\" quotes"

Regards,
-- 
Andreas Gustafsson, [email-masked]