Subject: [DNSOP] DNS Camel Viewer

From: bert hubert <[email-masked]>
Date: Sat, 24 Mar 2018 17:51:15 +0100

Hi everyone,

[tl;dr, check out https://powerdns.org/dns-camel/ ]

As a first step in attempting to not only whine about a glut of DNS
standards, I've made an easy to update viewer of all DNS relevant standards.

The good news is, if we filter out obsoleted, historical, informational and
BCP documents, we are left with a lot less pages. The bad news is, 1403
pages remain. 

I took the set of RFCs from https://www.isc.org/community/rfcs/dns/ and
augmented this with the recent RFCs published by DNSOP and DPRIVE. 

The page is on https://powerdns.org/dns-camel/ - it is a bit slow to load
because it sources the 12MB IETF XML file describing all RFCs. It should do
this only once and then be fast. 

The goal is to augment this view with all drafts that are currently active,
so we can also see "what is coming".

If you know of RFCs that should or should not be on the list, please edit
dns-rfcs.js on https://github.com/ahupowerdns/dns-camel/

It is my hope that this view will be helpful in determining:

1) What to obsolete
2) The "must read" list for:
	a) stub resolvers
	b) dns caches / resolvers
	c) authoritative servers
3) The "must not read" list - documents not worth it to obsolete, but
considered confusing or misguided
4) Perhaps take a good look at the drafts we are currently working on

	Bert

---

From: Matthew Pounsett <[email-masked]>
Date: Sat, 24 Mar 2018 12:56:51 -0400

> BCP documents, we are left with a lot less pages. The bad news is, 1403

I'd suggest you should also filter out ops documents like RFC6781, since
those serve to clear up the complexity rather than contribute to it.  I'll
send a pull request in a bit with the ones I've spotted.

---

From: Matthew Pounsett <[email-masked]>
Date: Sat, 24 Mar 2018 14:04:02 -0400

> send a pull request in a bit with the ones I've spotted.
I went to go dig into this and in the process of producing a list I found
that the list was longer than I imagined, and that there are more
categories of documents that don't contribute to the camel than I thought.
 Rather than immediately send a pull request I've decided to share my
attempt at categorizing of non-camel documents here to invite discussion on
whether they should be included in the camel list, or not, and to allow for
others to spot things I've either mis-categorized or missed.

My main criteria for putting something on one of these lists is that
implementers not be in the intended audience for the document.  That is, if
the document doesn't directly contribute to a decision about whether or how
to write code, it should appear here.

There's an additional category that I didn't dig into that actually
contributes negatively to the camel: deprecations (e.g. RFC 6563).

Operational Guides
rfc1033
rfc1713
rfc1912
rfc2100
rfc2182
rfc3258
rfc4339
rfc4367
rfc4472
rfc4955
rfc5358
rfc6781
rfc7534
rfc7535
rfc7583
rfc7706
rfc7793

Proposals
rfc1535

Essays and Comments
rfc1178
rfc1591
rfc2826
rfc3071
rfc3467
rfc6305

Correspondence between parties (?)
rfc1401

Summaries of Discussions and other "Current Status" documents
rfc2825
rfc3130
rfc7085
rfc7626

Requirements Documents and Problem Statements
rfc4892
rfc4986
rfc5507
rfc6168
rfc6761
rfc8244

Procedural and Policy Documents (for IANA & other non-operations groups)
rfc6335
rfc6841
rfc6895
rfc6912

---

From: bert hubert <[email-masked]>
Date: Sun, 25 Mar 2018 20:25:08 +0200

> categories of documents that don't contribute to the camel than I thought.

Hi Matthew,

I have indeed found the same thing. I've trawled the RFC index for anything
with "DNS" or "Domain Name System" in the title, and this found even more
documents that do not change the DNS itself, but do specify how to use it.

These documents may be worthy, but an implementer need not specifically
adhere to thse RFCs. 

There are 267 RFCs and active drafts that are "about" DNS right now.

I have begun to sort these into sections, tentatively:

Core: everyone needs to read this
DNSSEC: Could be skipped if you do not care about DNSSEC
rrtype: Define rrtypes that do not change semantics
dns-meta: Documents contemplating DNS
dns-use: Documents describing how to use DNS to do certain things

Probably more sections are possible. Some documents could be in multiple
sections. 

The file that contains my very limited work on assigning sections is:

https://github.com/ahupowerdns/protocol-camel/blob/master/dns-rfcs.js

I'd love for people to send pull requests improving the file.

Note that RFCs themselves are already grouped into 'Informational', 'Best
current practice' or even 'Experimental'. Almost everything that is an
operational guideline is already in 'Informational'. 

> to write code, it should appear here.

My goal is to list everything that has DNS as its main thrust, even if it
can be safely ignored because it merely specifies how DNS can be used for
something. The reason for listing this stuff is that this at least stores
the knowledge that this RFC is not required reading. This is then 'dns-use'.

These documents are hidden by the default filter settings.

> contributes negatively to the camel: deprecations (e.g. RFC 6563).

Yes - even though you still have to read them. 

> Operational Guides

So this overlaps hugely with "INFORMATIONAL" and "BCP", but indeed likely
still worth its own section.

> rfc1535

Unsure what to make of this document.

> rfc6305

This is likely my 'dns-meta' category.

> Correspondence between parties (?)

Perhaps we should have an 'oddball' category :-)

> Summaries of Discussions and other "Current Status" documents

dns-meta perhaps too?

> Requirements Documents and Problem Statements

Agree.

> Procedural and Policy Documents (for IANA & other non-operations groups)

Perhaps this could go with rfc1401 as 'procedural'?

	Bert

---

From: Shane Kerr <[email-masked]>
Date: Mon, 26 Mar 2018 08:03:00 +0000

Bert,

bert hubert:

Cool!

> dns-rfcs.js on https://github.com/ahupowerdns/dns-camel/

I think that's fine, but probably some discussion is necessary before a
PR? (I'm happy to send one if there seems to be general agreement.)

First, we have various IDNA work:

RFC 3492 defines Punycode
RFC 5890 is IDNA
RFC 5891 is IDNA

Certainly most DNS software does not know or care about label names, but
I guess IDNA can be included in one of the "dns-use" category that you
described?

Next, RFC 3646 describes an option for DHCPv6 which configures DNS. If
you are going to include this then you need to include every way that
anyone can configure DNS, everywhere. (Or at least the IPv6 DNS router
option...) I'd say just leave it out.

Finally, mDNS is not DNS, so RFC 6762 and RFC 6763 should probably be
removed, or possibly added to a new "things that seem like DNS but
actually have nothing to do with DNS, except when they do" category?

Cheers,

--
Shane

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 26 Mar 2018 10:15:18 +0200

Nice viewer :)

What immediately catches my eye is that the DNSSEC RFCs 4033-4034-4035 
are a Proposed Standard, and RFC 5011 is an Internet Standard. In fact, 
RFC 5011 is the only DNSSEC Internet Standard. That can't be right, 
right? :)

Matthijs

On 24-03-18 17:51, bert hubert wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Tony Finch <[email-masked]>
Date: Mon, 26 Mar 2018 14:02:13 +0100

> Unsure what to make of this document.

That's effectively security considerations and implementation advice for
stub resolvers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fisher: Variable 4, becoming east or southeast 5 or 6, occasionally 7 later.
Slight or moderate, becoming rough later in north. Showers. Good, occasionally
poor.