Subject: [DNSOP] Deprecating the status opcode

From: "John Dickinson" <[email-masked]>
Date: Wed, 15 May 2019 11:06:03 +0100

Hi,

In the spirit of deprecating things I have submitted a draft to deprecate the status opcode.

A new version of I-D, draft-dickinson-dnsop-deprecating-status-opcode-00.txt
has been successfully submitted by John Dickinson and posted to the
IETF repository.

Name:		draft-dickinson-dnsop-deprecating-status-opcode
Revision:	00
Title:		Depreciating the DNS Status OpCode
Document date:	2019-05-13
Group:		Individual Submission
Pages:		4
URL:            https://www.ietf.org/internet-drafts/draft-dickinson-dnsop-deprecating-status-opcode-00.txt
Status:         https://datatracker.ietf.org/doc/draft-dickinson-dnsop-deprecating-status-opcode/
Htmlized:       https://tools.ietf.org/html/draft-dickinson-dnsop-deprecating-status-opcode-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dickinson-dnsop-deprecating-status-opcode

Abstract:
   This document updates RFC1035 to depreciate the Status DNS OpCode.

John Dickinson

https://sinodun.com

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 15 May 2019 13:55:48 +0200

John,

> In the spirit of deprecating things I have submitted a draft to deprecate the status opcode.

This seems like the most non-controversial document ever in the history 
of documents. 👍

Cheers,

--
Shane

---

From: Jim Reid <[email-masked]>
Date: Wed, 15 May 2019 13:00:31 +0100

> On 15 May 2019, at 12:55, Shane Kerr <[email-masked]> wrote:
> 
> This seems like the most non-controversial document ever in the history of documents.

A non-controversial DNS doc at the IETF? That’ll be a first. :-)

---

From: Joe Abley <[email-masked]>
Date: Wed, 15 May 2019 08:01:09 -0400

On 15 May 2019, at 07:55, Shane Kerr <[email-masked]> wrote:

> This seems like the most non-controversial document ever in the history of documents. 👍

:-)

Can we deprecate opcode 1 while we're at it? Or has that already been done somewhere?

Joe

---

From: "John Dickinson" <[email-masked]>
Date: Wed, 15 May 2019 13:04:07 +0100

> Can we deprecate opcode 1 while we're at it? Or has that already been done somewhere?

Done in RFC3425

John Dickinson

https://sinodun.com

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 15 May 2019 19:26:51 +0530

> This seems like the most non-controversial document ever in the history of

ROFL!

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 15 May 2019 19:27:56 +0530

Hi John

> In the spirit of deprecating things I have submitted a draft to deprecate the status opcode.

In your support, there's atleast the "precedence" RFC deprecating
IQUERY. :)

		Mukund

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 15 May 2019 17:58:04 +0400

On Wed, May 15, 2019 at 2:06 PM John Dickinson <[email-masked]> wrote:

> A new version of I-D,
> draft-dickinson-dnsop-deprecating-status-opcode-00.txt
> URL:
> https://www.ietf.org/internet-drafts/draft-dickinson-dnsop-deprecating-status-opcode-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-dickinson-dnsop-deprecating-status-opcode/
> Htmlized:
> https://tools.ietf.org/html/draft-dickinson-dnsop-deprecating-status-opcode-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-dickinson-dnsop-deprecating-status-opcode
>
>
> Abstract:
This looks reasonable to me.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Chris Thompson <[email-masked]>
Date: 15 May 2019 17:36:32 +0100

On May 15 2019, Jim Reid wrote:

>> of documents.
>A non-controversial DNS doc at the IETF? That'll be a first. :-)

Well, I am sure some nit-picking can be organised. As well as RFC 1035,
surely the admirably concise definition of a status query in section 3.8
of RFC 1034 deserves to be mentioned?

There is pre-history as well, of course. In RFC 883 the opcodes 2 and 3
were assigned to "completion queries" CQUERYM and CQUERYU. Or rather, they
would have been except for an obvious typo which actually assigns 2 to
both of them [top of page 27]. It's quite shocking that no-one ever seems
to have filed an official erratum against RFC 883 about this!

RFC 1996 assigned opcode 4 to NOTIFY without any explanation as to why 3
might be, in some sense, already reserved.

-- 
Chris Thompson
Email: [email-masked]

---

From: Baden Hughes <[email-masked]>
Date: Thu, 16 May 2019 02:50:25 +1000

Once again in the long tradition of IETF nitpicking, should the term
"deprecating" be used throughout, rather than "depreciating" ?

Baden

---

From: "John Levine" <[email-masked]>
Date: 15 May 2019 13:00:20 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-

RFC 1034 says it's "To be defined" so this seems a little premature.

Other than that, go for it.

---

From: Bob Harold <[email-masked]>
Date: Wed, 15 May 2019 13:57:35 -0400

> Other than that, go for it.
Does this increase or decrease the 'camel' page count?

-- 
Bob Harold

---

From: Petr Špaček <[email-masked]>
Date: Thu, 16 May 2019 12:23:12 +0200

On 15. 05. 19 19:57, Bob Harold wrote:
> 
> On Wed, May 15, 2019 at 1:00 PM John Levine <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     In article <[email-masked]
>     <mailto:[email-masked]>> you write:
>     >-=-=-=-=-=-
>     >
>     >Hi,
>     >

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".

Just my two eurocents.

-- 
Petr Špaček  @  CZ.NIC

---

From: Ray Bellis <[email-masked]>
Date: Thu, 16 May 2019 11:50:49 +0100

> encounter them in pile of DNS RFCs".

Must as I like simple short documents, I'm inclined to agree.

I recently had an interesting debate with someone about the correct use 
of the flag bits for opcodes other than QUERY.

While some later docs do talk about uses of those bits for e.g. UPDATE, 
there's no place I could find that specifically says that header bits 
are opcode specific and MUST NOT be copied into the response without 
explicit (per-opcode) instruction.

Ray

---

From: Shane Kerr <[email-masked]>
Date: Thu, 16 May 2019 14:10:18 +0200

Petr,

> 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.

> 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

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 16 May 2019 17:53:12 +0530

> encounter them in pile of DNS RFCs".

+1 (matches up with "clarifications" style RFCs that bundle things
together).

		Mukund

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 May 2019 10:13:09 -0400 (EDT)

> +1 (matches up with "clarifications" style RFCs that bundle things

That should be obvious from the IANA registry. If it is not, then we
should write something that instructs IANA to improve the registry.

Paul

---

From: Joao Luis Silva Damas <[email-masked]>
Date: Thu, 16 May 2019 16:48:04 +0200

> On 16 May 2019, at 12:23, Petr Špaček <[email-masked]> wrote:
> encounter them in pile of DNS RFCs”.

Agree. Also “obsolete” in a document often leads to the pursue of whatever obsoleted it and it is not always clear. A cleanup doc, ala “clarifications” would be a better approach

Joao

---

From: "Michael J. Sheldon" <[email-masked]>
Date: Thu, 16 May 2019 15:46:48 +0000

On 5/16/19 3:23 AM, Petr Špaček wrote:
> Notice: This email is from an external sender.
> 
> 
> 

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

---

From: tjw ietf <[email-masked]>
Date: Sun, 19 May 2019 13:31:20 -0400

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 <[email-masked]> wrote:
>

---

From: Dick Franks <[email-masked]>
Date: Sun, 19 May 2019 21:58:06 +0100

IMHO, not worth the effort

Dick Franks
________________________

---

From: "John Dickinson" <[email-masked]>
Date: Tue, 21 May 2019 11:13:03 +0100

Hi,

If the WG is interested, I am more than happy to have this doc stand alone or become/be merged into a bigger document.
The source is at https://github.com/Sinodun/deprecating-status-opcode PRs are welcome if someone wants to make this doc bigger.
I have corrected the spelling (thanks Baden).

regards
John

John Dickinson

https://sinodun.com