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

Andreas Gustafsson <gson@araneus.fi> Thu, 16 January 2014 17:54 UTC

Return-Path: <gson@araneus.fi>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D6D1A1F33 for <dnsop@ietfa.amsl.com>; Thu, 16 Jan 2014 09:54:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp4kXxIJnKfb for <dnsop@ietfa.amsl.com>; Thu, 16 Jan 2014 09:54:50 -0800 (PST)
Received: from gunvor.araneus.fi (gunvor.araneus.fi [46.246.126.150]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8451A1EF9 for <dnsop@ietf.org>; Thu, 16 Jan 2014 09:54:49 -0800 (PST)
Received: from guava.gson.org (unknown [10.0.1.240]) by gunvor.araneus.fi (Postfix) with ESMTP id AE373145854; Thu, 16 Jan 2014 17:54:36 +0000 (UTC)
Received: by guava.gson.org (Postfix, from userid 101) id 9A76B75E36; Thu, 16 Jan 2014 19:54:36 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21208.7388.614870.591922@guava.gson.org>
Date: Thu, 16 Jan 2014 19:54:36 +0200
To: Paul Vixie <paul@redbarn.org>
In-Reply-To: Re: <52D6E0AB.807@redbarn.org>
References: <52D298FB.3080100@redbarn.org> <52D6E0AB.807@redbarn.org>
X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf)
From: Andreas Gustafsson <gson@araneus.fi>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: [DNSOP] Passive DNS - Common Output Format (draft-dulaunoy-kaplan-passive-dns-cof-01)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 17:54:53 -0000

Paul Vixie wrote:
> 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, gson@araneus.fi