Re: [DNSOP] Deprecating the status opcode

2019-05-21 Thread John Dickinson
On 19 May 2019, at 18:31, tjw ietf wrote:

> Can we like this draft *and* a RFC cleanup of 1034/1035?
>
> Though watching tcpm do this for 793 has been disheartening

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

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


signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-19 Thread Dick Franks
IMHO, not worth the effort

Dick Franks



On Sun, 19 May 2019 at 18:31, tjw ietf  wrote:
>
> 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  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  >>> > wrote:
> >>>
> >>>In article <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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-19 Thread tjw ietf
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  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 >> > wrote:
>>> 
>>>In article <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


Re: [DNSOP] Deprecating the status opcode

2019-05-16 Thread Michael J. Sheldon
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 > > wrote:
>>
>> In article <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


Re: [DNSOP] Deprecating the status opcode

2019-05-16 Thread Joao Luis Silva Damas


> On 16 May 2019, at 12:23, Petr Špaček  wrote:
> 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”.

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-16 Thread Paul Wouters

On Thu, 16 May 2019, Mukund Sivaraman wrote:


On Thu, May 16, 2019 at 12:23:12PM +0200, Petr Špaček wrote:

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


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


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-16 Thread Mukund Sivaraman
On Thu, May 16, 2019 at 12:23:12PM +0200, Petr Špaček wrote:
> 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".

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

Mukund

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-16 Thread Shane Kerr

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 mailto:jo...@taugh.com>> wrote:

 In article <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


Re: [DNSOP] Deprecating the status opcode

2019-05-16 Thread Ray Bellis



On 16/05/2019 11:23, Petr Špaček wrote:


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


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-16 Thread Petr Špaček
On 15. 05. 19 19:57, Bob Harold wrote:
> 
> On Wed, May 15, 2019 at 1:00 PM John Levine  > wrote:
> 
> In article <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".

Just my two eurocents.

-- 
Petr Špaček  @  CZ.NIC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-15 Thread Bob Harold
On Wed, May 15, 2019 at 1:00 PM John Levine  wrote:

> In article <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?

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-15 Thread John Levine
In article <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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-15 Thread Baden Hughes
Once again in the long tradition of IETF nitpicking, should the term
"deprecating" be used throughout, rather than "depreciating" ?

Baden

On Wed., 15 May 2019, 8:06 pm John Dickinson,  wrote:

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


Re: [DNSOP] Deprecating the status opcode

2019-05-15 Thread Chris Thompson

On May 15 2019, Jim Reid wrote:


On 15 May 2019, at 12:55, Shane Kerr  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. :-)


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: c...@cam.ac.uk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-15 Thread Loganaden Velvindron
On Wed, May 15, 2019 at 2:06 PM John Dickinson  wrote:

> 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.
>
>
This looks reasonable to me.


>
> John Dickinson
>
> https://sinodun.com
>
> Sinodun Internet Technologies Ltd.
> Magdalen Centre
> Oxford Science Park
> Robert Robinson Avenue
> Oxford OX4 4GA
> U.K.
> ___
> 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


Re: [DNSOP] Deprecating the status opcode

2019-05-15 Thread Mukund Sivaraman
Hi John

On Wed, May 15, 2019 at 11:06:03AM +0100, John Dickinson wrote:
> Hi,
> 
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-15 Thread Mukund Sivaraman
On Wed, May 15, 2019 at 01:55:48PM +0200, Shane Kerr wrote:
> John,
> 
> On 15/05/2019 12.06, John Dickinson wrote:
> > 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. 👍

ROFL!

Mukund

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-15 Thread John Dickinson
On 15 May 2019, at 13:01, Joe Abley wrote:

> On 15 May 2019, at 07:55, Shane Kerr  wrote:
>
>> On 15/05/2019 12.06, John Dickinson wrote:
>>> 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. 👍
>
> :-)
>
> 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

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


signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-15 Thread Joe Abley
On 15 May 2019, at 07:55, Shane Kerr  wrote:

> On 15/05/2019 12.06, John Dickinson wrote:
>> 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. 👍

:-)

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


Joe


signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-15 Thread Jim Reid


> On 15 May 2019, at 12:55, Shane Kerr  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. :-)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Deprecating the status opcode

2019-05-15 Thread Shane Kerr

John,

On 15/05/2019 12.06, John Dickinson wrote:

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop