Petr,
On 16/05/2019 12.23, Petr Špaček wrote:
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 disagree.
A new DNS developer may see "obsolete" on the IANA table and happily
ignore this, rather than scratching her head trying to figure out if it
is defined somewhere eventually, and searching through every RFC
published after 1035 to try to figure it out.
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".
The problem with this is that even something that should be as
non-controversial as deprecating MAILA/MAILB generated huge debate and
concern. I have doubts that any larger cleanup RFC will ever succeed.
Maybe we can convert *this* document into the One True Cleanup RFC. If
we can actually come up with any other cleanup that doesn't result in
wailing and gnashing of teeth, then we can add that in later?
Cheers,
--
Shane
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
