Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-nsec-ttl

From: Tim Wicinski <[email-masked]>
Date: Fri, 29 Jan 2021 10:22:02 -0500

All

After a quick check with the other chairs, we're ready to move this draft
forward.

This starts a Working Group Last Call for draft-ietf-dnsop-nsec-ttl

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/

The Current Intended Status of this document is: Proposed Standard
as it will update 4034, 4035, and 5155.

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on:  12
February 2021

thanks
tim

---

From: Michael StJohns <[email-masked]>
Date: Fri, 29 Jan 2021 12:31:22 -0500

On 1/29/2021 10:22 AM, Tim Wicinski wrote:
>
> All
>
> After a quick check with the other chairs, we're ready to move this 
> draft forward.
>
> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/>
>
> If someone feels the document is *not* ready for publication, please 
> speak out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on: 
>  12 February 2021
>
> thanks
> tim
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

Hi Tim et al -

Sorry - I completely missed this document earlier.

I can't support this as Standards track even though it purports to 
update standards as it doesn't actually specify an implementable 
protocol.   Basically, this is dependent upon humans doing the right 
thing, rather than specifying behavior of the protocol.

For each of these, I'd recommend specifying what a client does in each 
of the cases, rather than weasel wording the SHOULD with respect to the 
zone contents to turn this into an implementable protocol.

E.g. for each of these clauses add something similar to "The client 
SHOULD/MUST reduce the effective TTL for the received NSEC RR to the 
lesser of the TTL of the current SOA record,  the TTL of the SOA, and 
the TTL of the NSEC RR record and MUST discard the NSEC RR when that 
effective TTL expires."

So - not ready for last call.

Mike

---

From: Peter van Dijk <[email-masked]>
Date: Sun, 31 Jan 2021 17:23:14 +0100

Hello Michael,

On Fri, 2021-01-29 at 12:31 -0500, Michael StJohns wrote:
> I can't support this as Standards track even though it purports to update standards as it doesn't actually specify an implementable protocol.   Basically, this is dependent upon humans doing the right thing, rather than specifying behavior of the protocol.  

The updates in this document are reflected in software patches, not
human behaviour. What am I missing?

> For each of these, I'd recommend specifying what a client does in each of the cases, rather than weasel wording the SHOULD with respect to the zone contents to turn this into an implementable protocol.

Wow, what?

> E.g. for each of these clauses add something similar to "The client SHOULD/MUST reduce the effective TTL for the received NSEC RR to the lesser of the TTL of the current SOA record,  the TTL of the SOA, and the TTL of the NSEC RR record and MUST discard the NSEC RR when that effective TTL expires."

The client (I assume you mean a caching validating resolver) should not
do that at all. If the document suggests that to you, please help me
fix that.

Note that if we -did- wanted to write this, we couldn't - section 3.4
('No updates to RFC8198') explains why.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/