Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-11-18 Thread Vladimír Čunát
On 11/14/19 12:05 AM, Viktor Dukhovni wrote: > It'd be a shame (though admittedly not frequent) to have a resolver > retry over TCP just to get the same answer with additional information > it does not need and perhaps does not even understand. EDE codes themselves take very little space, so trunc

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-11-14 Thread Richard Gibson
I like this idea, and am aware of at least two other proposals that would (or would have) benefited from a new OPT record [EDNS header flag bit] to communicate "incomplete response" as distinct from "truncated response" (the latter encouraging retry over a transport supporting larger messages,

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-11-13 Thread Viktor Dukhovni
> On Nov 13, 2019, at 5:50 PM, Wes Hardaker wrote: > >>> I added this text to the next version: >>> >>> When the response grows beyond the requestor's UDP payload >>> size , servers SHOULD truncate messages >>> by dropping EDE options before dropping other data from >>> packet

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-11-13 Thread Wes Hardaker
Viktor Dukhovni writes: > > On Nov 13, 2019, at 12:56 PM, Wes Hardaker wrote: > > > > I added this text to the next version: > > > > When the response grows beyond the requestor's UDP payload > > size , servers SHOULD truncate messages > > by dropping EDE options before dropping

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-11-13 Thread Viktor Dukhovni
> On Nov 13, 2019, at 12:56 PM, Wes Hardaker wrote: > > I added this text to the next version: > > When the response grows beyond the requestor's UDP payload > size , servers SHOULD truncate messages > by dropping EDE options before dropping other data from > packets. Imp

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-11-13 Thread Wes Hardaker
Puneet Sood writes: > Independent of the decision on EDE forwarding and caching, the I-D > needs to have some guidance for it [truncation]. The EXTRA-TEXT field > may be obtained from configuration and it is possible that the > resulting DNS message will exceed UDP message size limit in the > req

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-11-13 Thread Wes Hardaker
"Jan Komissar (jkomissa)" writes: > In section 2, Extended DNS Error EDNS0 option format, it states that > the OPTION-LENGTH should be “4 + the length of the EXTRA-TEXT section… > .” This appears to be a remnant from when the option included a flag > word. I think it should be changed to “2 + the

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-11-08 Thread Petr Špaček
On 31. 10. 19 20:08, Eric Orth wrote: > On Fri, Oct 25, 2019 at 9:29 AM Petr Špaček > wrote: > > Would it be possible to get some time allocation of your UX design folks, > before we set the protocol in stone? > > > Not likely, unfortunately.  Downside of not hav

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-10-25 Thread Petr Špaček
On 24. 10. 19 19:56, Warren Kumari wrote: > On Tue, Oct 22, 2019 at 6:49 AM Tony Finch wrote: >> >> Petr Špaček wrote: >>> >>> 2. Second problem is that it is uncelar if there is going to be a >>> consumer: Did *anyone* from stub resolvers said a word about this draft? >>> Is it useful as it is?

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-10-25 Thread Petr Špaček
On 24. 10. 19 19:24, Eric Orth wrote: > On Tue, Oct 22, 2019 at 6:49 AM Tony Finch > wrote: > > I expect almost no-one can do anything with EDE without > getaddrinfo() EAI_ return code extensions. > >   > In many cases, especially when DoH is in use, Chrome uses its

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-10-24 Thread Jan Komissar (jkomissa)
AM To: dnsop Subject: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error All We had such great comments the first time we did a Working Group Last Call for draft-ietf-dnsop-extended-error, that the chairs decided a second one would be even better. Before we start, a few

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-10-24 Thread Warren Kumari
On Tue, Oct 22, 2019 at 6:49 AM Tony Finch wrote: > > Petr Špaček wrote: > > > > 2. Second problem is that it is uncelar if there is going to be a > > consumer: Did *anyone* from stub resolvers said a word about this draft? > > Is it useful as it is? > > I expect almost no-one can do anything wit

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-10-23 Thread Patrick McManus
extended codes are pretty important in the DoH space - which doesn't require library intermediaries. IIRC the very important use case was disambiguating DNSSEC validation errors from other errors (as retry behavior could very well be different). So this has been eagerly anticipated. On Tue, Oct 22

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-10-22 Thread Puneet Sood
On Tue, Oct 22, 2019 at 6:49 AM Tony Finch wrote: > > Petr Špaček wrote: > > > > 2. Second problem is that it is uncelar if there is going to be a > > consumer: Did *anyone* from stub resolvers said a word about this draft? > > Is it useful as it is? > > I expect almost no-one can do anything wit

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-10-22 Thread Tony Finch
Petr Špaček wrote: > > 2. Second problem is that it is uncelar if there is going to be a > consumer: Did *anyone* from stub resolvers said a word about this draft? > Is it useful as it is? I expect almost no-one can do anything with EDE without getaddrinfo() EAI_ return code extensions. Tony. --

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-10-21 Thread Tim Wicinski
Petr Thanks for clarifying. I was going through so many notes, and needed a check. 1. Forwarding Semantics Let me think on this one with the authors and chairs. 2. Stub Resolvers. OK 3. Standards-Track vs Not That's more than reasonable. Tim On Mon, Oct 21, 2019 at 1:48 PM Petr Špaček w

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-10-21 Thread Petr Špaček
On 21. 10. 19 19:18, Tim Wicinski wrote: > > All > > The second WGLC period ended, and I needed a bit of time to go over all the > comments and make sure they were all addressed, and that appears to be true. > > The only thing I see are some comments were raised after the -12 version.  > They'

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-10-21 Thread Tim Wicinski
All The second WGLC period ended, and I needed a bit of time to go over all the comments and make sure they were all addressed, and that appears to be true. The only thing I see are some comments were raised after the -12 version. They've been addressed and can be updated on its way to IETF LC.

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-09-30 Thread Wes Hardaker
Vittorio Bertola writes: > > Il 28 settembre 2019 01:41 Wes Hardaker ha scritto: > > > > + Response: Those three codes were supplied in a previous comment > > round and they are supposed to indicate policies being applied from > > different sources. Can you check the new text of them

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-09-28 Thread Vittorio Bertola
> Il 28 settembre 2019 01:41 Wes Hardaker ha scritto: > > + Response: Those three codes were supplied in a previous comment > round and they are supposed to indicate policies being applied from > different sources. Can you check the new text of them to see if > they are more unders

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-09-27 Thread Wes Hardaker
"Michael J. Sheldon" writes: Thanks Michael, Thanks for the comments. Responses are inline below in my tracking notes below. 14.4 DONE Michael J. Sheldon" 14.4.1 DONE In section 3.21 --- 3.21. Extended DNS Error

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-09-27 Thread Wes Hardaker
Stephane Bortzmeyer writes: Thanks Stephane, Thanks for the comments. Responses are inline below in my tracking notes below. 14.3 DONE Stephane Bortzmeyer ~ IMHO, the document is good. I like the fact there is no longer a limitation of a given EDE to some RCODE

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-09-27 Thread Wes Hardaker
Puneet Sood writes: Hi Puneet, Thanks for the comments. Responses are inline below in my tracking notes below. 14.5 TODO Puneet Sood ~ I got around to review the draft only recently and have made an attempt to avoid points of discussion that have been resolved since

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-09-27 Thread Wes Hardaker
Loganaden Velvindron writes: > I'm ok with the latest revision. Awesome, thanks! > Just a small request: John Todd from quad9 sent his feedback, so it's > fair to credit him in the next revision of the draft. Yep, fixed. Thanks for that. -- Wes Hardaker USC/ISI _

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-09-21 Thread Viktor Dukhovni
> On Sep 20, 2019, at 5:17 PM, Puneet Sood wrote: > > Since the consensus is that the EDEs are purely diagnostic, it would > be good to reiterate that at the end of this paragraph. For the record, while that was "diagnostic" was my take on the purpose of these codes, reading other responses, I a

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-09-17 Thread Michael J. Sheldon
In section 3.21 3.21. Extended DNS Error Code 20 - Lame An authoritative server that receives a query (with the RD bit clear) for a domain for which it is not authoritative SHOULD include this EDE code in the SERVFAIL response. A resolver that receives a query (with the RD bit clear

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-09-17 Thread Stephane Bortzmeyer
On Thu, Sep 12, 2019 at 09:51:25AM -0400, Tim Wicinski wrote a message of 90 lines which said: > We had such great comments the first time we did a Working Group > Last Call for draft-ietf-dnsop-extended-error, that the chairs > decided a second one would be even better. IMHO, the document is

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-09-12 Thread Loganaden Velvindron
On Thursday, September 12, 2019, Tim Wicinski wrote: > All > > We had such great comments the first time we did a Working Group > Last Call for draft-ietf-dnsop-extended-error, that the chairs decided > a second one would be even better. > > Before we start, a few comments: > > - Viktor's comment

Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-09-12 Thread Viktor Dukhovni
On Thu, Sep 12, 2019 at 09:51:25AM -0400, Tim Wicinski wrote: > - Viktor's comments from 11 September will be rolled into the WGLC > comments, which means I'll be tracking them with the authors. Much appreciated, thanks! FWIW, on the hot topic of conflict between RCODE and extended RCODE, Paul

[DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

2019-09-12 Thread Tim Wicinski
All We had such great comments the first time we did a Working Group Last Call for draft-ietf-dnsop-extended-error, that the chairs decided a second one would be even better. Before we start, a few comments: - Viktor's comments from 11 September will be rolled into the WGLC comments, which mea