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

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

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

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

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

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

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

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

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

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 >

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

"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

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

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

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

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

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

Hi, I realize I’m late to this, but this should probably be fixed: 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

"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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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,