Subject: [apps-discuss] DNS work

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 21 Aug 2013 16:59:37 -0700

In giving the audio from IETF 87 a re-listen, it seems as if the two DNS
items we had at the end of the agenda had a non-trivial amount of
interest.  I wonder if we could engage the group about adopting some of
that here, or at least someplace in APPS.

The first is draft-levine-dnsextlang, which proposes a method to describe
the syntax of new DNS RRTYPEs so that various kinds of DNS software can
auto-provision.  There was explicit support from a few people for the
notion of doing this work, with some discussion about whether this would be
in the DNS itself or elsewhere.

The second was the two proposals by Andrew Sullivan and John Levine for
ways to add a mechanism to the DNS for identifying administrative
boundaries in the DNS.  It also got some discussion because there are some
extant (and in some cases long-lived) needs for this in the applications
space.

So two questions on each of these:

1) Is there support for doing this kind of work in the APPS area?  In
particular, is anyone prepared to commit to reviews and comments on this
sort of work if it were to appear formally in some way?

2) Again in each case, if the answer to the above is yes, is the work
appropriate for APPSAWG, or should the proponents look at getting BoFs
together (perhaps in time for Vancouver) to form separate working groups to
advance it?

-MSK, APPSAWG co-chair

---

From: Ned Freed <[email-masked]>
Date: Wed, 21 Aug 2013 17:32:24 -0700 (PDT)

> in the DNS itself or elsewhere.

I think this is very important work and strongly support it, although doing
it in APPS seems a little odd. But I care a lot less about where than I do
about getting it done.

> extant (and in some cases long-lived) needs for this in the applications

I don't know enough about this space to comment either way.

				Ned

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Aug 2013 19:12:43 -0600

> I don't know enough about this space to comment either way.

I'm more interested in the latter work than the former, but I suggest
that the proponents of both might try to generate some discussion,
feedback, and perhaps even implementation before we take the relevant
I-Ds on as WG items. I for one would volunteer to review both of the
administrative boundary documents.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "John Levine" <[email-masked]>
Date: 22 Aug 2013 02:01:47 -0000

>I-Ds on as WG items.

I'm currently rewriting my Web Crudware(tm) DNS front end and will do
the dns extension language stuff.  I believe that Tony Finch
implemnented a version of it last year.

R's,
John

---

From: "Jiankang Yao" <[email-masked]>
Date: Thu, 22 Aug 2013 15:30:25 +0800

From: Murray S. Kucherawy
Date: 2013-08-22 07:59
To: IETF Apps Discuss
Subject: [apps-discuss] DNS work

1) Is there support for doing this kind of work in the APPS area?  In particular, is anyone prepared to commit to reviews and comments on this sort of work if it were to appear formally in some way?
[Jiankang Yao]  I personally support this kind of work in APPS area. 

2) Again in each case, if the answer to the above is yes, is the work appropriate for APPSAWG, or should the proponents look at getting BoFs together (perhaps in time for Vancouver) to form separate working groups to advance it?

[Jiankang Yao] If it is in the APPSAWG, it may cause many discussion about DNS in this list. It seems that BOFs are better.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 22 Aug 2013 01:14:41 -0700

We don't need to constrain APPSAWG work to this list.  As we did with
webfinger (and should've done sooner), specific work items can get their
own lists if traffic warrants.  That is, however, sometimes a hint that the
work does warrant its own working group.

-MSK

On Thu, Aug 22, 2013 at 12:30 AM, Jiankang Yao <[email-masked]> wrote:

> **
>
>  *From:* Murray S. Kucherawy <[email-masked]>
> *Date:* 2013-08-22 07:59
> *To:* IETF Apps Discuss <[email-masked]>
> *Subject:* [apps-discuss] DNS work
>
>
> *[Jiankang Yao]*  I personally support this kind of work in APPS area.
>
> *[Jiankang Yao]* If it is in the APPSAWG, it may cause many discussion
> about DNS in this list. It seems that BOFs are better.
>
>

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Aug 2013 11:14:39 +0100

On 22/08/2013 00:59, Murray S. Kucherawy wrote:
> In giving the audio from IETF 87 a re-listen, it seems as if the two 
> DNS items we had at the end of the agenda had a non-trivial amount of 
> interest.  I wonder if we could engage the group about adopting some 
> of that here, or at least someplace in APPS.
>
> The first is draft-levine-dnsextlang, which proposes a method to 
> describe the syntax of new DNS RRTYPEs so that various kinds of DNS 
> software can auto-provision.  There was explicit support from a few 
> people for the notion of doing this work, with some discussion about 
> whether this would be in the DNS itself or elsewhere.
This looks like a useful piece of work. I have no opinion about the best 
place to do it.
>
> The second was the two proposals by Andrew Sullivan and John Levine 
> for ways to add a mechanism to the DNS for identifying administrative 
> boundaries in the DNS.  It also got some discussion because there are 
> some extant (and in some cases long-lived) needs for this in the 
> applications space.
>
> particular, is anyone prepared to commit to reviews and comments on 
> this sort of work if it were to appear formally in some way?

Yes, this is needed.

> together (perhaps in time for Vancouver) to form separate working 
> groups to advance it?

This is an interesting question. I don't have a gut feeling for how long 
it would take proponents to converge on 1 proposal (or decide that 2 are 
really needed, as they serve different puprose). A BoF sounds like a 
good idea. Possibly a non WG forming one.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Aug 2013 11:18:27 +0100

> extant (and in some cases long-lived) needs for this in the applications

I take it that these proposals aim to fix the problems of the
public-suffix list. That list is used in various places so it'd
be important that the different interests are involved and might
buy into using DNS instead.

A BoF to try figure out if a solution might get traction would seem
to be called for before discussing the venue for work.

S.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Aug 2013 08:16:24 -0600

On 8/22/13 4:18 AM, Stephen Farrell wrote:
> public-suffix list. 

That's how I see it.

> That list is used in various places so it'd

Agreed.

> to be called for before discussing the venue for work.

Sounds reasonable.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "John Levine" <[email-masked]>
Date: 22 Aug 2013 17:38:58 -0000

>buy into using DNS instead.

That was my intention.  It's slightly more urgent than it has been in
the past because draft-kucherawy-dmarc-base seems likely to become a
standards track RFC, and it uses public suffix.

>to be called for before discussing the venue for work.

Seems reasonable, although it's a sufficently well known problem that
I'd think we could get a reasonable sense of the situation in e-mail.

Andrew's proposal and mine are technically quite different, we later
realized because we're solving different technical problems that
happen both to use public suffix as the current kludge.

R's,
John

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Aug 2013 12:46:09 -0600

> happen both to use public suffix as the current kludge.

That's good to know. It would be helpful to capture that understanding
in your respective I-Ds.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "John Levine" <[email-masked]>
Date: 26 Aug 2013 03:20:34 -0000

>> in the DNS itself or elsewhere.

I just submitted draft-levine-dnsextlang-07 which cleans up the ABNF and
adds a version tag to the DNS records.

I also set up rrtype.info with definitions of all of the existing
RRTYPEs that I think I can describe with the existing language.  Visit
http://www.rrtype.info for a link to some resources or try, e.g.

$ dig mx.rrtype.info txt

;; QUESTION SECTION:
;mx.rrtype.info.			IN	TXT

;; ANSWER SECTION:
mx.rrtype.info.		7162	IN	TXT	"RRTYPE=1" "MX:15 Mail exchanger" "I2 Priority (lower values are higher priority)" "N[A,C] Host name"

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Tue, 27 Aug 2013 11:10:25 +0100

> implemnented a version of it last year.

I experimented but didn't manage to finish it. I haven't looked at your
recent drafts (sorry) but the early draft I started from was a bit too
limited to do what I wanted. My experiments were trying to work out an
RDATA description language that could be able to drive code that can:

(1) parse and serialize wire format
(2) parse and serialize presentation format
(3) generate a reasonably friendly form-based editing user interface

(There are obviously some complicated RDATA types that need special case
code, but generic code could cope with many of the existing types.)

Goal (2) implies that the description language needs to be able to handle
enumerations with symbolic values, if it is to support a fully standards-
conformant parser.

Goal (3) implies to me that you need field names, and named flag bit
values. (Many, but not all, of the existing RDATA specs include these
names.) This is so that the user interface can help the user enter the
data correctly. For instance, can you remember what the three numbers in a
SRV record mean? Field names also allow an implementation to have tables
mapping names to descriptions in different international languages.

It is hard to come up with a language that does this simply and
economically. I was trying out variations with a line per field with
indented lines for enumeration/flag values or special pragmas such as
name compression. I'm not sure how to squeeze something like this into the
DNS in a readable manner :-)

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.