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
