Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

* Paul Vixie: >> As a counterexample, RFC 6891 requires FORMERR responses without OPT >> RRs from implementations which do not support EDNS: >> >>Responders that choose not to implement the protocol extensions >>defined in this document MUST respond with a return code (RCODE) of >>FORM

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

Florian Weimer wrote: > * W. C. A. Wijngaards: > >> > +1. Backwards compatibility means you cannot specify that existing >> > implementations have to change. > > Does it matter if they do not exist or are not considered practically > relevant? not usually. if there's a standard for it, our burd

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

* W. C. A. Wijngaards: > +1. Backwards compatibility means you cannot specify that existing > implementations have to change. Does it matter if they do not exist or are not considered practically relevant? As a counterexample, RFC 6891 requires FORMERR responses without OPT RRs from implementat

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

Andrew Sullivan wrote: > On Thu, Mar 19, 2015 at 03:58:47AM -0700, Paul Vixie wrote: >> > >> > if you want new behaviour, negotiate for it. > > So you want a way to signal the new behaviour and negotiate that? i don't care whether there's new behaviour. but if new behaviour is going to be incom

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

On Thu, Mar 19, 2015 at 03:58:47AM -0700, Paul Vixie wrote: > > if you want new behaviour, negotiate for it. So you want a way to signal the new behaviour and negotiate that? It strikes me that the EDNS0 option that Paul Wouters wrote up was intended to offer such signalling, and people thought

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

> Andrew Sullivan > Thursday, March 19, 2015 3:56 AM > > No RFC can make changes that apply to implementations that do not > conform with that RFC. This is true by definition. The draft does > not somehow magically retroactively change the text in RFC 1035. It > s

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

On Thu, Mar 19, 2015 at 09:56:56AM +0100, W.C.A. Wijngaards wrote: > > +1. Backwards compatibility means you cannot specify that existing > implementations have to change. You can specify that 'upgraded' > implementations perform new actions, of course. No RFC can make changes that apply to imp

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Paul, On 18/03/15 09:59, Paul Vixie wrote: >> Stub and recursive resolvers MUST be able to process responses >> that arrive in a different order to that in which the requests >> were sent, regardless of the transport protocol in use. > > this do

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

Ray Bellis wrote: >> > On 18 Mar 2015, at 12:37, John Kristoff wrote: >> > >> > That is the exact same language used in IETF RFC 5966. The original >> > document, along with this draft still says it "makes no specific >> > recommendations to operators of DNS servers". It is written for >> >

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

> On 18 Mar 2015, at 12:37, John Kristoff wrote: > > That is the exact same language used in IETF RFC 5966. The original > document, along with this draft still says it "makes no specific > recommendations to operators of DNS servers". It is written for > "implementors". This seems to be a c

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

On Wed, 18 Mar 2015 01:59:56 -0700 Paul Vixie wrote: > >This document therefore updates the core DNS protocol > > specifications such that support for TCP is henceforth a REQUIRED > > part of a full DNS protocol implementation. > this language is too strong, and breaks working configurations

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

On Wed, Mar 18, 2015 at 10:08:23AM +, Tony Finch wrote: > I think the recommended limits in that paragraph are OK only if viewed > from the perspective of individual client programs. The above quote is > correct in that there's no sensible way for the server to enforce the > limit - never min

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

Andrew Sullivan wrote: > > In section 6, there's this: > > The server MUST NOT enforce these rules for a particular >client because it does not know if the client IP address belongs to a >single client or is, for example, multiple clients behind NAT. > > I don't think that MUST NOT is

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

i have read draft-ietf-dnsop-5966bis-01, and i have some comments. tl;dr: this document is nowhere near ready to ship. > ... > >This document therefore updates the core DNS protocol specifications >such that support for TCP is henceforth a REQUIRED part of a full DNS >protocol impleme

[DNSOP] remarks on draft-ietf-dnsop-5966bis-01

Dear colleagues, I have read draft-ietf-dnsop-5966bis-01. I have some comments. To begin with, I must say that the draft is in really very good shape and I think it more or less ready to ship. Good work. I support the document and believe it should be published as an RFC once a couple small is