Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-06

[Peter van Dijk]

Hi Duane,

On Fri, 2023-08-18 at 15:52 +, Wessels, Duane wrote:
> > 
> > I don't have a strong suggestion for rewording. Perhaps replace "recursive
> > clients generally" with "some recursive clients might"? I can also live with
> > the current text, but I did want to point out this nuance.
> > 
> 
> Peter, thanks for the feedback.
> 
> How about this change to that paragraph?
> 
>Upon receipt of a FORMERR response, some recursive clients will retry
>their queries without EDNS(0), while others will not.  Nonetheless,
>resolution failures from FORMERR responses are rare.

Looks good to me, thanks.

Kind regards,
-- 
Peter van Dijk
PowerDNS.com B.V. - https://www.powerdns.com/

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

Re: [DNSOP] IETF117 Chairs Actions

[tjw ietf]

I need to double checkBut also stip on avoid fragmentation. I missed somethingTim Sent from my iPhoneOn Aug 18, 2023, at 13:07, Warren Kumari  wrote:Heyya,Just confirming that I can start IESG Eval on draft-ietf-dnsop-caching-resolution-failures?I'm assuming so, but…WOn Wed, Aug 16, 2023 at 6:57 PM, Tim Wicinski  wrote:All,Thanks for another productive session of DNSOP.  Paul's minutes have been uploaded. If you made comments at the microphone, please confirm everything is accurate. https://datatracker.ietf.org/doc/minutes-117-dnsop/https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-ietf117/dnsop-ietf117-minutes.txtActions draft-ietf-dnsop-caching-resolution-failuresWork to resolve questions on caching timeout value text. Good Discussions, let's have more:draft-ietf-dnsop-cds-consistencydraft-ietf-dnsop-compact-denial-of-existenceCall For Adoptions:draft-thomassen-dnsop-generalized-dns-notifywas going to do this after 116, ended up with the discussion on two NOTIFY draftsdraft-bash-rfc7958bisThis appears straightforward.draft-bellis-dnsop-qdcount-is-oneRay will move Historical Text to appendix,then will send out Call Current ordered list of Working Group Last Call documents:draft-ietf-dnsop-dnssec-bootstrapping draft-ietf-dnsop-rfc8109bisdraft-ietf-dnsop-svcb-daneMore Discussion:draft-grubto-dnsop-dns-out-of-protocol-signalingmaybe ready for adoption?draft-johani-tld-zone-pipelinedraft-dnsop-multi-alg-rules

___

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] IETF117 Chairs Actions

[Warren Kumari]

Heyya,

Just confirming that I can start IESG Eval on
draft-ietf-dnsop-caching-resolution-failures

?

I'm assuming so, but…

W


On Wed, Aug 16, 2023 at 6:57 PM, Tim Wicinski  wrote:

> All,
>
> Thanks for another productive session of DNSOP.  Paul's minutes have been
> uploaded. If you made comments at the microphone, please confirm everything
> is accurate.
>
> https://datatracker.ietf.org/doc/minutes-117-dnsop/
>
> https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-ietf117/
> dnsop-ietf117-minutes.txt
>
>
> Actions
>
> draft-ietf-dnsop-caching-resolution-failures
>
>
>-
>
>Work to resolve questions on caching timeout value text.
>
>
> Good Discussions, let's have more:
>
>
>-
>
>draft-ietf-dnsop-cds-consistency
>
>
>
>-
>
>draft-ietf-dnsop-compact-denial-of-existence
>
>
>
> Call For Adoptions:
>
>
>-
>
>draft-thomassen-dnsop-generalized-dns-notify
>-
>
>   was going to do this after 116,
>   -
>
>   ended up with the discussion on two NOTIFY drafts
>
>
>
>-
>
>draft-bash-rfc7958bis
>-
>
>   This appears straightforward.
>
>
>
>-
>
>draft-bellis-dnsop-qdcount-is-one
>-
>
>   Ray will move Historical Text to appendix,
>   -
>
>   then will send out Call
>
>
> Current ordered list of Working Group Last Call documents:
>
>
>-
>
>draft-ietf-dnsop-dnssec-bootstrapping
>
>
>
>-
>
>draft-ietf-dnsop-rfc8109bis
>
>
>
>-
>
>draft-ietf-dnsop-svcb-dane
>
>
>
> More Discussion:
>
>
>-
>
>draft-grubto-dnsop-dns-out-of-protocol-signaling
>-
>
>   maybe ready for adoption?
>
>
>
>-
>
>draft-johani-tld-zone-pipeline
>
>
>
>-
>
>draft-dnsop-multi-alg-rules
>
>
> ___
> 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] Publication has been requested for draft-ietf-dnsop-avoid-fragmentation-14

[Petr Špaček]

On 18. 08. 23 17:33, Peter van Dijk wrote:

Hello Tim,

On Wed, 2023-08-16 at 15:45 -0700, Tim Wicinski via Datatracker wrote:

Tim Wicinski has requested publication of 
draft-ietf-dnsop-avoid-fragmentation-14 as Best Current Practice on behalf of 
the DNSOP working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/


In
https://mailarchive.ietf.org/arch/msg/dnsop/lrPbp6B8Mkz2S7HBXlxSPoIhTOw/
I pointed out that zero of the implementers honour item 2 in section 3.1.

In
https://mailarchive.ietf.org/arch/msg/dnsop/QOxTZHG03UVLom9E-y6iYG5s6po/
you said "good point, we need to address this".

After that I have seen no communication on the list about addressing
this, so I'm very surprised to see this publication request.


FTR I agree that this document does not describe Best _Current_ 
Practice, and to underline the point I add that

>  D.1. BIND 9
> BIND 9 does implement recommendation 2 of Section 3.2.

... does not seem to be correct. None of the values is used, and none of 
the MAY methods is employed by BIND (in current versions).


--
Petr Špaček
Internet Systems Consortium

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

Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-06

[Wessels, Duane]

> On Aug 14, 2023, at 1:40 AM, Peter van Dijk via Datatracker 
>  wrote:
> 
> Reviewer: Peter van Dijk
> Review result: Ready with Nits
> 
> Thank you for processing my previous comments. The document is in great shape.
> I have one nit:
> 
> One of the new sections based on my earlier comments is "2.7.  FORMERR
> Responses". It currently says
> 
>> Upon receipt of a FORMERR response, recursive clients generally retry their
> queries without EDNS(0).
> 
> For most resolver implementations (Knot, Unbound, PowerDNS, but not BIND), 
> this
> is only true if the FORMERR response does not contain EDNS(0)/OPT. There are
> auths out there that send FORMERR+OPT responses, and they are not getting
> non-EDNS0 fallback behaviour from such resolvers.
> 
>> Thus, resolution failures from FORMERR responses are rare.
> 
> This, meanwhile, remains true. When they happen, they tend to be persistent,
> and noticed, leading to fixes.
> 
> I don't have a strong suggestion for rewording. Perhaps replace "recursive
> clients generally" with "some recursive clients might"? I can also live with
> the current text, but I did want to point out this nuance.
> 

Peter, thanks for the feedback.

How about this change to that paragraph?

   Upon receipt of a FORMERR response, some recursive clients will retry
   their queries without EDNS(0), while others will not.  Nonetheless,
   resolution failures from FORMERR responses are rare.

DW


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

Re: [DNSOP] Publication has been requested for draft-ietf-dnsop-avoid-fragmentation-14

[Peter van Dijk]

Hello Tim,

On Wed, 2023-08-16 at 15:45 -0700, Tim Wicinski via Datatracker wrote:
> Tim Wicinski has requested publication of 
> draft-ietf-dnsop-avoid-fragmentation-14 as Best Current Practice on behalf of 
> the DNSOP working group.
> 
> Please verify the document's state at 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/

In
https://mailarchive.ietf.org/arch/msg/dnsop/lrPbp6B8Mkz2S7HBXlxSPoIhTOw/
I pointed out that zero of the implementers honour item 2 in section 3.1.

In
https://mailarchive.ietf.org/arch/msg/dnsop/QOxTZHG03UVLom9E-y6iYG5s6po/
you said "good point, we need to address this".

After that I have seen no communication on the list about addressing
this, so I'm very surprised to see this publication request.

Kind regards,
-- 
Peter van Dijk
PowerDNS.com B.V. - https://www.powerdns.com/

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