Subject: [DNSOP] DNSOP Meeting in Orlando/IETF86

From: Peter Koch <[email-masked]>
Date: Thu, 7 Feb 2013 12:14:46 +0100

Dear WG,

your chairs have requested a one hour slot for the Orlando meeting. We have
a set of things to discuss, which we will present in the draft agenda soon,
but we would also like to solicit suggestions for agenda items from you.
Please direct your ideas to <[email-masked]>.

-Stephen & Peter

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 18 Feb 2013 11:05:17 +0100

On Thu, Feb 07, 2013 at 12:14:46PM +0100,
 Peter Koch <[email-masked]> wrote 
 a message of 12 lines which said:

> we would also like to solicit suggestions for agenda items from you.

A few minutes to discuss draft-bortzmeyer-dns-json, "JSON format to
represent DNS data"? I'm specially interested by feedback about the
open questions listed in section 3.6 of -00

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Feb 2013 08:22:47 -0800

> open questions listed in section 3.6 of -00

+1 to this being an agenda item. There are some other DNS operational things that would much simpler if there was a single format like this, and I would like to see the WG take this up.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Mon, 18 Feb 2013 11:27:13 -0500

> +1 to this being an agenda item. There are some other DNS operational things that would much simpler if there was a single format like this, and I would like to see the WG take this up.

Plus another one…

W

> 
> --Paul Hoffman
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 

-- 
Militant Agnostic -- I don't know and you don't either...

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Feb 2013 00:48:25 +0000

> open questions listed in section 3.6 of -00

I think your first question, about a formal mechanism for documenting the
field names of DNS RDATA, ought to be answered by draft-levine-dnsextlang.

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: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Feb 2013 16:59:32 +0100

On Tue, Feb 19, 2013 at 12:48:25AM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 15 lines which said:

> about a formal mechanism for documenting the field names of DNS
> RDATA, ought to be answered by draft-levine-dnsextlang.

draft-levine-dnsextlang is not published yet and, more important, it
is not implemented. The rrtype.arpa and rrname.arpa zones have not
been created and therefore we do not have the DNS records describing
the existing RR types.

Also, the descriptions in draft-levine-dnsextlang are optional (if
they are missing, what name to use for the JSON members?)

Finally, the syntax for the descriptions in draft-levine-dnsextlang
will not always yield "friendly" JSON members (for instance because of
white space). So, we need at least to specify a derivation algorithm
(s/\s+/_/ ?)

---

From: Tony Finch <[email-masked]>
Date: Wed, 27 Feb 2013 16:09:30 +0000

> > RDATA, ought to be answered by draft-levine-dnsextlang.

I should clarify that by "ought" I meant that the problem it is trying to
solve is extremely close to the problem that you have, and I think both
problems should have the same solution.

> they are missing, what name to use for the JSON members?)

Perhaps they should not be optional.

> white space). So, we need at least to specify a derivation algorithm

Better I think to adjust dnsextlang to be closer to the needs of
programming languages including JSON.

Tony.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Feb 2013 08:24:37 -0800

> been created and therefore we do not have the DNS records describing

But, even more significantly, draft-levine-dnsextlang is for defining the structure of RDATA, not the entire value of an RR. A JSON format for RRs would have data that is not in RDATA, such as TTL. The two proposals are for very different things.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Wed, 27 Feb 2013 16:27:55 +0000

Paul Hoffman <[email-masked]> wrote:
>
> But, even more significantly, draft-levine-dnsextlang is for defining
> the structure of RDATA, not the entire value of an RR. A JSON format for
> RRs would have data that is not in RDATA, such as TTL. The two proposals
> are for very different things.

But you can't describe the structure of an RR without describing its
RDATA. They aren't different things: one is a sub-part of the other.

Tony.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Feb 2013 08:49:28 -0800

> RDATA. They aren't different things: one is a sub-part of the other.

Of course. For the RDATA part of a JSON structure, you can be very JSON-y, or very masterfile-y like draft-levine-dnsextlang has gone. I would prefer being JSON-y because the rest of the data we are talking about is already in that format, and we would not be reliant on anyone understanding the new proposed format from draft-levine-dnsextlang.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Wed, 27 Feb 2013 17:18:32 +0000

Paul Hoffman <[email-masked]> wrote:
>
> Of course. For the RDATA part of a JSON structure, you can be very
> JSON-y, or very masterfile-y like draft-levine-dnsextlang has gone. I
> would prefer being JSON-y because the rest of the data we are talking
> about is already in that format, and we would not be reliant on anyone
> understanding the new proposed format from draft-levine-dnsextlang.

I don't see draft-levine-dnsextlang as being particularly masterfile-y.
What it gives you is a sequence of type + name pairs. These can be used to
serialize to/from wire format or presentation format. They should be
equally useful for serializing to/from JSON. Or to/from a web form for
user-friendly editing.

(Several RR types are too complicated so will need special handling; but
you can just view this as extending the set of RDATA field types that the
description language knows about.)

A key advantage to having machine-readable RDATA descriptions is that they
should be general-purpose so you don't have to keep reinventing the wheel
each time you want a new representation: you can re-use the mapping
between RR types and seqences of fields, and just add a new mapping
between fields and your new representation.

Tony.

---

From: "John Levine" <[email-masked]>
Date: 27 Feb 2013 17:54:01 -0000

>programming languages including JSON.

It's a draft.  I'd be delighted to change it to make it more useful to
people.

R's,
John