On 24 March 2018 at 12:56, Matthew Pounsett <m...@conundrum.com> wrote:

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

Reply via email to