Can we like this draft *and* a RFC cleanup of 1034/1035? Though watching tcpm do this for 793 has been disheartening
From my high tech gadget > On May 16, 2019, at 11:46, Michael J. Sheldon <mshel...@godaddy.com> wrote: > >> On 5/16/19 3:23 AM, Petr Špaček wrote: >> Notice: This email is from an external sender. >> >> >> >>> On 15. 05. 19 19:57, Bob Harold wrote: >>> >>> On Wed, May 15, 2019 at 1:00 PM John Levine <jo...@taugh.com >>> <mailto:jo...@taugh.com>> wrote: >>> >>> In article <064ba295-f3dd-46e4-86a9-e03cf68eb...@sinodun.com >>> <mailto:064ba295-f3dd-46e4-86a9-e03cf68eb...@sinodun.com>> you write: >>>> -=-=-=-=-=- >>>> >>>> Hi, >>>> >>>> In the spirit of deprecating things I have submitted a draft to >>> deprecate the status opcode. >>> >>> RFC 1034 says it's "To be defined" so this seems a little premature. >>> >>> Other than that, go for it. >>> >>> >>> Does this increase or decrease the 'camel' page count? >> >> Personally I think it is not worth the effort, it will just add one more >> RFC to read and does not help the protocol maintenance. >> >> I would say that it is better to have one "cleanup" RFC instead of >> one-off doc with one useful paragraph in it. With one bigger document we >> could say to newcommers "this is list of things you can ignore when you >> encounter them in pile of DNS RFCs". >> > > In a perfect world, we'd have occasional complete rewrites like what > happened with RFCs 821, 2821, 5321 and RFCs 822, 2822, 5322 > > > > -- > Michael Sheldon > Dev-DNS Services > GoDaddy.com > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
