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

[Andreas Gustafsson <[e-mail]>]

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, [e-mail]