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
