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

From: Alexandre Dulaunoy <[email-masked]>
Date: Thu, 27 Feb 2014 17:57:12 +0100

On 02/27/2014 05:43 PM, L. Aaron Kaplan wrote:

Thanks for feedback and updates.

> So, the changes are currently in our github repository. Waiting for Alexandre to submit them again.

The -02 is now available at

https://github.com/adulau/pdns-qof/blob/master/to-submit/draft-dulaunoy-kaplan-passive-dns-cof-02.txt

It will be pushed to I-D submission when it's back ;-)

""
The cut-off time for the I-D submission was 00h UTC, 2014-02-15.
The I-D submission tool will be reopened at 00h local time at the IETF
meeting location, 2014-03-03.
""

Cheers.

- -- 
Alexandre Dulaunoy
CIRCL - Computer Incident Response Center Luxembourg
41, avenue de la gare L-1611 Luxembourg
[email-masked] - www.circl.lu

---

From: "L. Aaron Kaplan" <[email-masked]>
Date: Thu, 27 Feb 2014 17:43:51 +0100

Hi Tony,

Thanks a lot for your very valuable feedback.

On Jan 16, 2014, at 3:27 PM, Tony Finch <[email-masked]> wrote:

> Paul Vixie <[email-masked]> wrote:
> 
>> 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/
> 
> A few questions / comments:
> 
> The ws non-terminal isn't defined. I guess it is supposed to be
> 
> 	ws = *( %x10 / %x09 )
> 
I agree. You probably meant 

   ws              = *(
                       %x20 |              ; Space
                       %x09                ; Horizontal tab
                      )

?

> 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?)
> 
Fixed , thanks for pointing this out.

> 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.
> 
Fixed

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

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

> I guess time stamps are represented as JSON numbers.
> 
Yes

> How are sensor_id octet strings encoded as JSON strings?
> 
Correct.

See you next week.

a.

> 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.
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

--- 
// L. Aaron Kaplan <[email-masked]> - T: +43 1 5056416 78
// CERT Austria - http://www.cert.at/
// Eine Initiative der nic.at GmbH - http://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg

---

From: Tony Finch <[email-masked]>
Date: Thu, 27 Feb 2014 17:04:37 +0000

> I agree. You probably meant

Er yes, typo :-)

> > How are sensor_id octet strings encoded as JSON strings?

I need a bit more clarification than that :-) Section 3.5.1 of the -01
version of your draft says that a sensor_id is an opaque octet string,
which cannot safely be encoded as a JSON string because JSON strings have
to be valid UTF-8.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Plymouth, Biscay, FitzRoy: West, veering northwest, 7 to severe gale 9,
perhaps storm 10 later. Very rough or high, occasionally very high. Rain or
showers. Moderate, occasionally poor.

---

From: "L. Aaron Kaplan" <[email-masked]>
Date: Thu, 27 Feb 2014 18:15:29 +0100

On Feb 27, 2014, at 6:04 PM, Tony Finch <[email-masked]> wrote:

> I need a bit more clarification than that :-)
All right then :)

> Section 3.5.1 of the -01
Okay, quite a nice catch. I would not have noticed that.

Since I am the only user of the sensor_id field right now, I'd say we remove the 
text:
  "The sensor_id is an opaque byte string as defined by RFC 5001 in
   section 2.3 [RFC5001].  The sensor_id MUST be escaped as defined in
   section 2.6 of RFC4627 [RFC4627]."
and just leave:
  "This field returns the sensor information where the record was seen. 
   This field is represented as a JSON [RFC4627] string."

Would that be OK for you?

---

---

From: Tony Finch <[email-masked]>
Date: Thu, 27 Feb 2014 17:38:15 +0000

> Would that be OK for you?

I think that makes sense because I can't see any reason to put non-UTF-8
junk in that field.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber: Southwest, backing east, 4. Slight, occasionally moderate. Showers.
Good.

---

From: Sebastian Castro <[email-masked]>
Date: Fri, 28 Feb 2014 09:25:06 +1300

> speaking for the authors of the draft below, i request adoption by

Hi Paul and the rest of the authors.

> 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.
> 

I've read the 02 draft and I have a couple of comments:

- In section 3.3, it reads:
   rdata MAY be an array as defined in JSON [RFC4627].
   Implementors of this draft MUST be able to deal with rdata being
   returned as JSON array or alternatively as a JSON string.

Thinking as a developer, it could be annoying to have to test if rdata
is a string or an array. Given JSON arrays can be empty, wouldn't be
better to express it always as an array?

- In section 3.4.1 count
   Specifies how many authoritative DNS answers were received at the
   Passive DNS Server's collectors with exactly the given set of values
   as answers (i.e. same data in the answer set - compare with the
   uniqueness property in "Mandatory Fields").  The number of requests
   is expressed as a decimal value.

If you collector is sitting in front of a recursor, that uses an
upstream recursor (forwarder), the number of answers you are going to
see it won't be the same of the number of authoritative answers. Given
this, should count be an object like

   { 'total': integer,
     'auth': integer }

or be expressed in different fields?

Finally, is there a reason why TTL are being omitted from the collection
and responses?

Cheers,

> ...

-- 
Sebastian Castro
Technical Research Manager
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 495 2337
mobile: +64 21 400535