On Thu, Mar 20, 2025 at 12:28 AM Petr Špaček <pspa...@isc.org> wrote:
> TL;DR > In the light of an experiment outlined below, using a current version of > Unbound, I'm not convinced the protocol in this draft is proven to work. > Most importantly, it does not have running code for section 5.1, which > is advertised as security measure in the discussions during this WGLC. > > Based on this observation, I claim draft version -09 is not suitable for > publication as a Standards Track RFC. > Petr, I don't have time right now to review your lengthy investigation of the Unbound implementation, and will defer to Willem to respond later. But let me make a few quick points: As far as I'm aware, Unbound has the "basic" revalidation feature that was originally described in 2009 and 2010 in the resolver-side-mitigations (Wijngaards) and res-improve (Vixie, Joffe, Neves) drafts. I'm sure they will have a complete implementation once this doc is published. There have also been other implementations in the field, but I'm not familiar with them. A complete running code implementation is NOT a requirement for a document to be initially published on the Standards Track (although per the IETF motto, running code is always highly desirable). To quote RFC 2606, Section 4.1: https://datatracker.ietf.org/doc/html/rfc2026#section-4.1 (I quickly scanned the many RFCs that "Update" 2606, but none appear to have revised this section at all, and some re-confirm it). 4.1.1 Proposed Standard The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level. A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. [...] Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
